Requirement Engineering

Requirement engineering and management
- Jay
October 15, 2008
Convergys Confidential and Proprietary

Fact - 1
2
Fact -2
3
Fact - 3
4
Fact - 4
5
Where is the exact problem ?
6
How it differs?
Which one you choose?
7
Importance of requirements
8
Where Requirement management fits?
9
What it costs?
10
Requirement - Definition
Defining a good requirement

As requirements are the foundation of any development project, teams need to
understand the attributes of a “good” requirement. The best requirements are:
• Correct (technically and legally possible)
• Complete (express a whole idea or statement)
• Clear (unambiguous and not confusing)
• Consistent (not in conflict with other requirements)
• Verifiable (it can be determined that the system meets the
requirement)
• Traceable (uniquely identified and tracked)
• Feasible (can be accomplished within cost and schedule)
• Modular (can be changed without excessive impact)
• Design-independent (does not pose a specific solution on design)
Each requirement must first form a complete sentence, containing a subject and
a predicate. These sentences must consistently use the verb “shall”, “will” or
“must” to show the requirement's mandatory nature, and “should” or “may” to
show that the requirement is optional.
11
Requirement engineering
Requirements engineering is a sub-discipline of software engineering

that focuses on discovering, analyzing, specifying and managing the
system requirements.
A systematic approach to
- Eliciting, organizing, and documenting the requirements of the system, and
- Establishing and maintaining agreement between the customer and the project
team on the changing requirements of the system.
Appropriate mechanism for understanding what the customer wants, analyzing needs,
negotiating a reasonable solution, validating the specification and managing changes in
requirements.
Requirement management:
Requirements are real capabilities which the system must provide. It
makes sense therefore to find out what the requirements are, write them
down and organize them, and manage them in the event that they
change. Stated another way we'll define requirements management as a
systematic approach to eliciting, organizing, and documenting the
requirements of a system.
12
Why requirement engineering?
To capture the specific requirements that must be achieved to build

high-quality software.
If we don’t engineer the requirements:

In most systems, It’s highly likely that you’ll build a very elegant software
solution that solves a wrong problem.
The result is:
Wasted time and money
Personal frustration
Unhappy Users
13
Who does requirement engineering?
Depending on project complexity a team of:
Software engineer
System analyst
Business analyst
Requirements specifier
Requirements Reviewer
Other Stakeholders
14
The framework
15
The real connected environment
16
RE - Process
17
Requirements elicitation
Requirements Elicitation is a process during which product requirements

are elicited from a variety of sources. Possible sources of information for
this task are the customer, end user, any other stakeholder, books,
existing applications, domain knowledge, organizational standards or
constraints and any other rules or regulations. Various techniques can be
used for eliciting requirements
18
Requirement elicitation - Techniques
- Interviews
- Surveys
- Data mining
- Questionnaires
- Market analysis
- Focus groups
- Future workshops
- Soft system methodology
- Co-operative requirements capture
- Scenario based requirements elicitation
- Multiple Viewpoint Requirements Capture
- Observation and Social Analysis
- Designer as Apprentice
19
Interviews
Interviewing is a technique where requirements engineers and different stakeholders

communicate directly with each other.
Interviews are usually conducted in a question-answer format with the intention of
eliciting the required information for system development.
There are two types of interviews:

-Structured
-Unstructured
Structured:
In the structured interview, the requirements engineer prepares a list of specific
questions and collects responses for them from the customer.
Unstructured:
An unstructured interview is a discussion between the requirements engineer and
stakeholders about the problem concepts and concerns of users. Here the requirements
engineer makes note of certain topics to be discussed
*Needs experience
*Both the interviewer and interviewee must have proper background knowledge and
excellent communication skills.
20
Surveys, Questionnaire and Data mining
Surveys and questionnaires

List of questions regarding the problem domain or concerns is prepared and
distributed to the customers.
Responses are collected and analyzed to study the customer needs. In order to get valuable
responses,
*It is important to properly design the questionnaire and distribute it to the appropriate sample
population
Data Mining
Used to analyze and extract useful patterns from the data collected.
-
-Mining the data about customers such as the responses to a product survey or customers’
reaction to a new technology, can draw important conclusion about their needs.
These techniques are useful if the proposed product is targeted towards a large number of
customers. In such cases, information gathered from a few customers will not be sufficient.
Surveys and Questionnaires can be used to obtain information from a large number of customers.
Data mining techniques can be used to analyze the data obtained from those surveys to identify
different classes of customers and
*Certain patterns or relationships in their needs. However, it is always difficult to get a good
and representative number of responses to surveys. In addition to this, the list of questions
prepared should be relevant and should be distributed to the right sample population.
21
Market analysis
The process of analyzing the product market for its current and
future trends is called market analysis.
Market analysis is a good technique to elicit requirements for a
system.
Gathering information about the competitor products would help to
identify the features that are not present in current products
Market analysis is a good technique to analyze similar products in

the market. It can reveal how technologies may change in the near
future.
It can also predict changes in customer’s demands. Using these
details, organizations can make decisions about selecting certain
features or technologies for their products.
*However, in order to obtain good results from the analysis, the
market expert must be well experienced and should have the skill to
collect the required information.
22
Focus groups
-Focus groups are group session approaches, where requirements engineers

observe and study users’ needs.
Groups of users are allowed to discuss in a free environment certain problem

-
concepts under the supervision of the requirements engineer.

-The requirements engineer acts as the facilitator and his role is passive. When
the users discuss with each other, the requirements engineer can learn
about what they think about the product and what they actually want
from the product
-Since the users are allowed to discuss in a free environment, problems that
occur due to a lack of communication can be reduced. It is easier to participate
in a free discussion than in a structured interview.
-In addition to this, when different customers discuss certain topic, it is easy to
identify requirements conflicts and to resolve them.
* However, the requirements engineer must have good listening and problem
solving skills. Also when several different customers discuss together, it is
important to maintain proper coordination between them.
23
Future workshops
-Future workshops are group session approaches similar to

focus groups.
-In a future workshop session, the current problem situation

is discussed, future visions of the systems are generated and
possible solutions to realize those visions are discussed
-During the process, any changes in the technologies or

product features that may occur in the future can be
foreseen.
-Using these details, the organization can not only make

better selections for its current product, but also develop
plans for its future products.
24
Soft system methodology
-SSM is a system development framework that allows for system analysis from
both the organizational and technical perspective.
-Unlike traditional system development processes, which focus only on solving

the technical requirements, SSM tries to analyze the problem situation and
proposes necessary organizational changes to improve the organizational
structure and processes.
SSM has several distinctive stages.

1.Problem Situation Unstructured
2.Problem Situation Expressed
3.Building Root Definitions of relevant systems
4.Conceptual modeling
5.Comparison with the real world
6.Implementing the feasible and desirable changes
It also supports communication between the management and technical personnel. In

addition to this, systems are analyzed from different viewpoints by defining several
root
definitions. This would identify conflicts in customer requirements or in different
viewpoints.
25
Cooperative Requirements Capture (CRC)
-Cooperative requirements capture is another group session approach for

requirements
engineering. The idea is to include not only the users and designers but also those
who
have a stake in the product.
-In this approach all the stakeholders together explore the user environment and
develop a shared vision of the future system.
-During the group session, participants discuss the current user activities and
envision any possible changes that might occur in future.
-The advantage of using the CRC approach for requirements engineering is that it
involves all the stakeholders in the decision making process.
-Due to this, the needs of different stakeholders can be easily understood. Since all
the stakeholders explore and develop a shared understanding of the current and
future visions of the product, it is possible to identify requirement changes and
conflicts early in the development process.
-In addition to this, it supports communication between the participants.
26
Scenario Based Requirements Elicitation
-User requirements are collected using a set of interaction scenarios.
-A scenario is a particular instance of the system’s use describing the

interactions between the system and users of the systems.
-Having understood the problem concept, different scenarios can be

identified by consulting the system users. Scenarios can be
documented using a format that is suitable for the organization.
-Regardless of the format, each scenario must include information

about the pre-condition, post-condition, normal and any exceptions in
the flow of event and any other parallel activities
-It is easier for the customer to describe how he or she performs

certain sequences of activities than answering a list of questions or
simply stating the needs. In addition to this, individual scenarios are
easier to understand and design rather than a whole system.
27
Multiple Viewpoint Requirements Capture
Helps to collect system requirements from different viewpoints.

-
-
Different stakeholders will have different requirements that the

-
system needs to fulfill.
Each stakeholder has his/her own viewpoint on the services that the
-
system should provide and the way in which it should be provided.

-In this approach, different viewpoints of the system are identified and
the requirements for each viewpoint are collected separately
This technique enables to study the system from different viewpoints.

-
-Requirements gathered from each viewpoint can be analyzed to

identify requirements conflicts.
Through proper negotiations, most appropriate requirements can be

-
selected. On the other hand, it is a very good technique to develop a

generic product that satisfies the needs of different customers.
28
Observation and Social Analysis
-Occasionally, it is difficult to elicit requirements just by talking to the users

or
asking questions. Users are often experts in performing jobs rather than
describing how they do them. In such cases, observing and recording the
users
working in their real environment for a considerable amount of time can
provide
a lot of information about their requirements.
These techniques includes
Ethnographic studies - where an ethnographer observes and records a group
-
of users working in their real work place
-When there is a lack of domain knowledge in the organization,
Observations and Social Analysis are good techniques to elicit system
requirements.
Example
If the system being developed is completely new, developers may not have
adequate domain knowledge required for product development. Sometimes
users are not capable of explaining how they perform certain tasks and what
they want from the product. In such cases, this is a very good technique for
requirements capturing.
29
Designer as apprentice
This is a technique where the designers learn from the user about
•
their work.
Here user is the master and designer is the apprentice who learns by
•
watching and listening to the user.
The idea behind this technique is to provide the designer with some
•
practical knowledge about the end user’s working environment and

his/her requirements on the proposed system
Getting some practical knowledge about the user’s work practice

•
helps designers to better understand their needs.
It also promotes communication between the user and designer.

•
However, to get good results, the designers should have excellent

learning skills.
30
Requirement analysis
A feasibility study and cost-benefit analysis of the product development process may be conducted
and the scope of the system is determined.
Customer requirements are analyzed and requirements conflicts if any are resolved.
Requirements analysis ensures that the system is going to provide the services that the customers
require. It also helps the designer to understand the customer requirements.
 For product line development, the requirements analysis stage involves:
 Identification of commonalities and variabilities in the domain
 Identification of potential members and their features and modeling them to get a better
understanding of the family.
Once the common and variable requirements are identified, potential products and their
features are selected. Using these details, the feasibility of developing those products as a
family is analyzed.
Aspects to choose product members and their features,
• Company strategies
• Customer’s priority
• Market advantage
• Contribution to the domain and
• The competition
Market Analysis is a good technique that can provide some useful information regarding the current
And future market trends and information about other products in the market. Based on the results
of this analysis, products and their features can be selected. Once the products and features are
selected, they must be modeled. Modeling enhances the understandability and simplifies the design.
Depending on the product line approach used suitable modeling techniques can be used.
31
Requirement analysis - Techniques
- Structured system analysis (SSA)

- Object oriented analysis (OOA)
- Joint application design (JAD)
- Quality function deployment (QFD)
- Participatory design
SSA:
- Function-oriented requirements analysis
- Data-flow diagrams can be used to represent the flow of data between various
tasks in the domain whereas entity-relationship diagrams can be used to
represent various domain entities and their relationships.
- Data dictionaries and entity-relationship models.
OOA:
- Use case diagrams are suitable for modeling requirements from the user’s perspective
and high-level class diagrams can be used to model requirements from the designer’s
perspective. Unified Modeling Language (UML) is a widely used object-oriented
modeling language
- Flow of messages between the objects and the evaluation of changes in their states due
to events or any other stimuli
32
JAD:
- JAD is a group session requirements analysis and design approach developed by
IBM.
- JAD is a group session approach that involves users in the system design.
- All the stakeholders can participate in the decision-making process. Activities such as
defining high-level requirements and bounding system scope can be extended to
identify product line requirements and characterize individual products in the family.
- JAD defines six different roles of participants who should participate in a session: a
session leader or facilitator, a system analyst, a specialist, a user representative, an
information system representative and the executive sponsor.
33
QFD:
QFD is an approach developed in Japan to produce quality products in the automotive industry in
1986.
• It focuses on translating customer requirements into technical requirements throughout the
product development process.
• The entire QFD process focuses on a house of quality, which maps customer requirements to the
proposed product features.
• Each development phase can use its own house of quality. QFD for the planning phase is used for
requirements analysis.
• Participants are asked to rate each requirement according to their relevance to a particular feature.
In addition to this, correlation between various technical features, customer’s importance of each
requirement and market evaluation of the competitive features are also considered.
• Based on the subjective analysis of the above factors, the final product features are selected. Thus
the QFD approach helps to develop quality features that are important to customers
• QFD is a good approach to select product features and to make high-level design decisions. It
encourages the organization to consider factors such as customer’s priority and competition for
requirements analysis.
34
Participatory design:
The Participatory Design approach allows designers and users to work

together.
Several techniques including Future Workshops, Cooperative

Prototyping, Design mock-ups and Future Games are used in
Participatory Design
Since this approach involves users in the system design, problems that
may occur due to a lack of communication can be avoided.
All the users can participate in the decision making process.
Designers can learn more about users’ needs by actually doing their work.
Users can work with the designer to learn about the design and to verify that the
design is going to meet all their needs.
35
Requirement specification
SRS:
Each product in the family must be specified separately and there should
be proper traceability mechanisms between the family and individual
product requirements.
A SRS document is developed for each family member as well as for the
entire family. While writing the family SRS, all the common and
variable requirements must be documented.
XML
XML can be used to specify product line requirements. Since XML

allows hierarchical representation of data, common and variable
requirements can easily be represented.
36
Requirement validation
Requirements Validation is concerned with checking the requirements for omissions, correctness, precision
conflicts and ambiguities and for ensuring that the requirements follow quality standard
Requirement reviews
Domain experts
Requirements engineers
Customers and
Stakeholders.
Prototyping
System prototypes can de developed to demonstrate the system behavior before the final product is being
developed.
Users have an opportunity to really see how the final system is going to behave and they can provide any
feedback
regarding possible misunderstandings or any other changes in the requirements.
Types:
- Throwaway prototyping (discarded)
- Evolutionary prototyping (adapted)
37
Requirement validation
-Requirement testing
• Requirements can also be verified by defining test cases for each

requirement.
• Test cases must be defined for both the common and variable
requirements.
• Once the member products and their features are selected, test cases
can be defined for each requirement so that products can be tested
against each requirement at the end.
• During the process, it is possible to identify any defect or problems in
the requirements.
38
Requirement validation review - Checklist
Sample checklist:
• Clarity
• Completeness
• Compliance
• Consistency
• Correctness
• Data usage
• Functionality
• Interface
• Level of detail
• Maintainability
• Performance
• Reliability
• Testability
• Traceability
39
Requirement management techniques
Understand the following about requirements:

-Scope creep can happen , So Beware !
-Instability typically results from problems with scope and understanding
-Traceability failures result in broken links, increased instability and POOR QUALITY of product
Introduce a method or tool for configuration management
Introduce a method or tool for traceability
Implement requirements with fields that will be appropriately altered throughout the SDLC
- Models
- Metrics
40
41
42
Requirement management metrics
Number of requirements.
Status of each requirement.
Number of requirement changes.
Kind of change.
Reason for change.
Cost of change.
Change Requested by Whom.
Functionality of the requirement.
Functionality of the software.
The preceding 9 metrics will be gathered on an ongoing basis. It therefore will be

possible to determine the current value of any of the measurements at any point in time.
• Requirement by type
• Requirement by status
• Requirement by time
• Requirement by changes
43
Conclusion and Summary
Requirement management should be given as much weight as

requirements development
Effective requirements management includes:
- General understanding of requirements trouble spots

- Configuration management
- Traceability
- Implementation of key requirement fields
This will provide an environment where requirements become a guiding

light that helps keep the project on track
44
45

Requirement Engineering

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Requirement Engineering

Uploaded by

Copyright:

Available Formats

Requirement engineering and management

October 15, 2008

Convergys Confidential and Proprietary

Which one you choose?

Defining a good requirement

Requirements engineering is a sub-discipline of software engineering

To capture the specific requirements that must be achieved to build

If we don’t engineer the requirements:

Depending on project complexity a team of:

Requirements Elicitation is a process during which product requirements

Interviewing is a technique where requirements engineers and different stakeholders

There are two types of interviews:

Surveys and questionnaires

Market analysis is a good technique to analyze similar products in

-Focus groups are group session approaches, where requirements engineers

Groups of users are allowed to discuss in a free environment certain problem

concepts under the supervision of the requirements engineer.

-Future workshops are group session approaches similar to

-In a future workshop session, the current problem situation

-During the process, any changes in the technologies or

-Using these details, the organization can not only make

-Unlike traditional system development processes, which focus only on solving

SSM has several distinctive stages.

It also supports communication between the management and technical personnel. In

-Cooperative requirements capture is another group session approach for

-In addition to this, it supports communication between the participants.

-User requirements are collected using a set of interaction scenarios.

-A scenario is a particular instance of the system’s use describing the

-Having understood the problem concept, different scenarios can be

-Regardless of the format, each scenario must include information

-It is easier for the customer to describe how he or she performs

Helps to collect system requirements from different viewpoints.

Different stakeholders will have different requirements that the

system needs to fulfill.

system should provide and the way in which it should be provided.

This technique enables to study the system from different viewpoints.

-Requirements gathered from each viewpoint can be analyzed to

Through proper negotiations, most appropriate requirements can be

selected. On the other hand, it is a very good technique to develop a

-Occasionally, it is difficult to elicit requirements just by talking to the users

watching and listening to the user.

practical knowledge about the end user’s working environment and

Getting some practical knowledge about the user’s work practice

helps designers to better understand their needs.

It also promotes communication between the user and designer.

However, to get good results, the designers should have excellent

- Structured system analysis (SSA)

The Participatory Design approach allows designers and users to work

Several techniques including Future Workshops, Cooperative

All the users can participate in the decision making process.

XML can be used to specify product line requirements. Since XML

• Requirements can also be verified by defining test cases for each

Understand the following about requirements:

The preceding 9 metrics will be gathered on an ongoing basis. It therefore will be

Requirement management should be given as much weight as

Effective requirements management includes:

- General understanding of requirements trouble spots

This will provide an environment where requirements become a guiding

You might also like