Requirements analysis
Speaker: Chuang-Hung Shih
Date: 2009.3.24
Understanding what the customer
wants
 Analysis should come early in any project, and
the most important part of that analysis is the
gathering of business requirements.
 Learn about product and process requirements
and how to effectively determine and prioritize
customer needs.
 Business requirements are statements that
describe what the customer and major
stakeholders need and want.
All about requirements
 Product requirements
 Product requirements describe the business needs in
terms of the main deliverables or products that are
created
 Process requirements
 Process requirements describe how people interact
with a product and how a product interacts with other
products.
 Prioritize the requirements
 Fulfilling some requirements requires much more
effort and cost than others.
Beware of false requirements
 If you could ask your customers what their
requirements were and have them respond
with everything they needed. A number of
challenges must be overcome:
 No single customer normally knows all of the
requirements up front.
 Different customers have different visions of what the
business needs are.
 Requirements are vague.
 Many statements are not requirements.
Success criteria
 The table below lists the criteria for software project
success in order of importance.
Requirements analysis process
 Requirements analysis process: Requirements elicitation,
analysis and specification.
 Requirements analysis is the process of understanding
the customer needs and expectations from a proposed
system or application and is a well-defined stage in the
Software Development Life Cycle model.
 Software requirements analysis and documentation
processes are critical to software project success.
Requirements analysis process
 Steps in the requirements analysis process.
 I. Fix system boundaries

This initial step helps in identifying how the new application
integrates with the business processes, how it fits into the larger
picture and what its scope and limitations will be.
 II. Identify the customer

In more recent times there has been a focus on identifying who the
'users' or 'customers' of an application are.
 III. Requirements elicitation
 IV. Requirements Analysis Process

Once all stakeholder requirements have been gathered, a
structured analysis of these can be done after modeling the
requirements.
 V. Requirements Specification
 VI. Requirements Management
Requirements elicitation


Information is gathered from the multiple stakeholders
identified.
Problems faced in Requirements Elicitation.






Ambiguous understanding of processes
Inconsistency within a single process by multiple users
Insufficient input from stakeholders
Conflicting stakeholder interests
Changes in requirements after project has begun
Tools used in Requirements Elicitation. Some of the current
Requirements Elicitation tools in use are:





Prototypes
Use cases
Data flow diagrams
Transition process diagrams
User interfaces
Requirements specification
 Requirements, once elicited, modeled and
analyzed should be documented in clear,
unambiguous terms.
 To overcome this, Requirements Specifications
may be documented separately as
 User Requirements - written in clear, precise
language with and use cases, for the benefit of the
customer and end-user
 System Requirements - expressed as a
programming or mathematical model, addressing the
Application Development Team and QA( Quality
Assurance) and Testing Team.
Your project's analysis phase should
yield three critical documents
 When the analysis phase of an application
development project ends, a manager should
know what the application looks like, how it
functions, and how it is designed.
 The three important deliverables created
during this phase are:
 The business requirements report.
 The conceptual systems design plan.
 The strategy documents.
The business requirements report
 High-level requirements

This section defines the big-picture requirements that are common to the
entire solution.
 Functional requirements

These are the more specific requirements.

This section should describe the client’s criteria for accepting the application,
if it has not already been described elsewhere.
 Acceptance criteria
 Process model

If you created process models of the solution, they should be included here,
along with the appropriate descriptions.
 Data model
 Additional information

Depending on the project and the particulars of the analysis phase, you
may also need to include any assumptions made in the analysis
process and other models, such as context diagrams, process
decompositions, and entity diagrams.
Conceptual systems design plan
 High-level technical architecture

This is a place to start laying out the technical solution. It should be diagram
at a high level that the business customer can understand.
 Screen layouts

However, a better way is to work with the business client to define what the
screens should look like and then design and code to those general
specifications.
 Report layouts

Work with your clients to define the reports that are needed and the general
columns and selection criteria of the reports.
 Interfaces

At this point, you should have a general idea of the internal and external
interfaces needed for the solution.
High-level strategy documents
 Testing strategy

The purpose of the testing strategy is to define the overall context for the
entire testing process. The process depends on the specific characteristics of
your solution.
 Training strategy

The information includes a training overview, the training needs of the
stakeholders, the types of training to be offered, and how the training will be
built and delivered.
 Data conversion strategy

In this document, you describe at a high level how data will be converted
from the current applications to the new application.
 Implementation strategy

When your application is completed, it may need a formal deployment
strategy. This document provides a general overview of deployment, when it
will occur, the complexities and risks, any assistance at the deployed sites,
and other relevant details.
User Participation in Software
Development Projects

It Is commonly acknowledged that success In IT projects is
difficult to achieve. A recent industry survey observed that only
34% of IT projects were considered successful.

Of the several potential factors contributing to this hard-toachieve success, user involvement was noted as the most
important one.

Researchers and practitioners have viewed user participation
as an important way of improving software quality and
increasing user satisfaction and acceptance.

On the other hand, empirical evidence shows that user
participation in the development process can negatively
influence project performance since it could make the process
more difficult, lengthy, and less effective.
User Participation in Software
Development Projects

This article addresses the question of the relative effectiveness
of user participation by empirically examining the perceived
software project performance (for example, satisfaction) from
both user and developer perspectives simultaneously.

We used survey data from 117 software development projects
and 746 respondents at a large Fortune 100 manufacturing
firm during a four-year time period to investigate the impact of
user participation on the satisfaction of both developers and
users.

In addition, we also study the role of software complexity (for
example, whether projects involve new software development
as opposed to maintenance of existing software) in user
participation and its effect on satisfaction.
User Participation in Software
Development Projects
 Questionnaire data was collected from 453 software
developers and 293 users/customers working on 117
software projects.
 Of the 117 software development projects, 45 (39% of
our sample) were maintenance projects and 72 (61%)
were new development projects. The average software
development time of the 117 software projects was 126
days.
The Level of User Participation
 Projects with nonzero participation greater than the
median (> 0.462) were categorized as high participation.
Of the 72 new development projects, 19 (26%) had low
(very minimal), 26 (36%) had moderate, and 27 (38%)
had high user participation.
 On the other hand, of the 45 maintenance projects, 15
(33%) had low, 16 (36%) had moderate, and 14 (31%)
had high user participation in the development process.
New Development Project Satisfaction
 Low user-participation


An X-shaped effect suggests that users were most satisfied while developers
were significantly less satisfied in the low (minimal) user-participation
situation.
Developers, under such circumstances, were likely to find greater difficulty
in resolving requirements and product feature ambiguities.
New Development Project Satisfaction
 Moderate user-participation



Users participated for an average of 3.88 workdays for a 100 function point
project, implying 28 workdays of customer effort for an average new
development project (711 function points, corresponding to 127 calendar
days).
In other words, users invested approximately 22% as much as the overall
project development time.
Even though the satisfaction levels were not at their highest, developers and
users seemed to reach a common ground when users engage only
moderately in the development process.
 High user-participation


In our sample, a project in this group (high participation), exhibited an
average of 105 workdays of customer participation, in comparison to 28workday effort for a moderate participation project, for an average of 127workday project.
Users participate to such extreme levels, their expectations of project
outcomes could also be exceptionally high. These users are then very
unlikely to be satisfied if actual project outcomes do not perform to their
high expectations
Maintenance Project Satisfaction
 Low user-participation


Both software developers and users were unlikely to be fully satisfied with
low user-participation in maintenance projects.
This effect may be due to the fact that software maintenance is a task that
is fairly difficult to execute and manage effectively due to added complexity
of understanding prior written code and prior corrective repairs on the
baseline software code.
Maintenance Project Satisfaction
 Moderate user-participation


That is, users participated approximately 15% as much as the overall
project development time.
When users are involved in such maintenance projects (moderate
participation), they might be able to lower developers' frustration and
enhance developers' overall software comprehension since users tend to
know more about the features in the original software.
 High user-participation


In our data, users and developers were relatively less satisfied when users
participated for approximately 75 workdays (60% of the overall project
development time).
Even if the original software is well-developed, the maintenance task is
relatively less complicated, and the overall maintenance project is completed
with fairly minimal changes in scope, the high expectations of users might
remain unsatisfied. At the same time, software developers are likely to be
unhappy with over demanding customers/users.