of 49
8/11/2019 Lecture 02 RE Process
1/49
Requirements
Engineering PROCESS
SWENG 580: advanced software
engineering
What are the principal
requirements engineering
activities?
8/11/2019 Lecture 02 RE Process
2/49
EngineeringDivision
,ThePennsylvaniaStateUniversity
2
SWENG 580: Advanced Software Engineering
What is the requirements engineering
process?
The processes used for requirements engineering vary widely
depending on the application domain, the people involved and the
organization developing the requirements
However, there are a number of generic activities common to all
processes Requirements elicitation Requirements analysis
Requirements validation
Requirements management
8/11/2019 Lecture 02 RE Process
3/49
EngineeringDivision
,ThePennsylvaniaStateUniversity
3
SWENG 580: Advanced Software Engineering
Requirements engineering process
Preliminary
Study
Requirements
Validation
Requirements
Definition
Requirements
Elicitation
Feasibility
Report Domain
Model
Requirements
Document
Definition of
Requirements
Requirements
Specification
8/11/2019 Lecture 02 RE Process
4/49
EngineeringDivision
,ThePennsylvaniaStateUniversity
4
SWENG 580: Advanced Software Engineering
Feasibility studies
A feasibility study decides whether or not the proposed system isworthwhile
A short focused study that checks If the system contributes to organizational objectives
If the system can be engineered using current technology and within budget
If the system can be integrated with other systems that are used
8/11/2019 Lecture 02 RE Process
5/49
EngineeringDivision
,ThePennsylvaniaStateUniversity
5
SWENG 580: Advanced Software Engineering
Feasibility study implementation
Based on information assessment (what is required), informationcollection and report writing
Questions for people in the organization What if the system wasnt implemented?
What are current process problems?
How will the proposed system help? What will be the integration problems?
Is new technology needed? What skills?
What facilities must be supported by the proposed system?
8/11/2019 Lecture 02 RE Process
6/49
EngineeringDivision
,ThePennsylvaniaStateUniversity
6
SWENG 580: Advanced Software Engineering
Elicitation and analysis
Sometimes called requirements elicitation or requirements discovery
Involves technical staff working with customers to find out about the
application domain, the services that the system should provide and
the systems operational constraints
May involve end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc. These are calledstakeholders
8/11/2019 Lecture 02 RE Process
7/49
EngineeringDivision
,ThePennsylvaniaStateUniversity
7
SWENG 580: Advanced Software Engineering
Problems with requirements analysis
Stakeholders dont know what they really want
Stakeholders express requirements in their own terms
Different stakeholders may have conflicting requirements
Organizational and political factors may influence the system
requirements
The requirements change during the analysis process. New
stakeholders may emerge and the business environment change
8/11/2019 Lecture 02 RE Process
8/49
EngineeringDivision
,ThePennsylvaniaStateUniversity
8
SWENG 580: Advanced Software Engineering
Social and organizational factors
Software systems are used in a social and organizational context.This can influence or even dominate the system requirements
Social and organizational factors are not a single viewpoint but are
influences on all viewpoints
Good analysts must be sensitive to these factors but currently no
systematic way to tackle their analysis
8/11/2019 Lecture 02 RE Process
9/49
EngineeringDivision
,ThePennsylvaniaStateUniversity
9
SWENG 580: Advanced Software Engineering
Example
Consider a system which allows senior management to accessinformation without going through middle managers Managerial status: Senior managers may feel that they are too important to use a
keyboard. This may limit the type of system interface used
Managerial responsibilities: Managers may have no uninterrupted time where they
can learn to use the system
Organizational resistance: Middle managers who will be made redundant maydeliberately provide misleading or incomplete information so that the system will fail
8/11/2019 Lecture 02 RE Process
10/49
EngineeringDivision
,ThePennsylvaniaStateUniversity
10
SWENG 580: Advanced Software Engineering
Requirements checking
Validity: Does the system provide the functions which best supportthe customers needs?
Consistency: Are there any requirements conflicts?
Completeness: Are all functions required by the customer included?
Realism: Can the requirements be implemented given available
budget and technology
Verifiability: Can the requirements be checked?
8/11/2019 Lecture 02 RE Process
11/49
EngineeringDivision
,ThePennsylvaniaStateUniversity
11
SWENG 580: Advanced Software Engineering
Requirements validation
Concerned with demonstrating that the requirements define thesystem that the customer really wants
Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an
implementation error
8/11/2019 Lecture 02 RE Process
12/49
EngineeringDivision
,ThePennsylvaniaStateUniversity
12
SWENG 580: Advanced Software Engineering
Requirements validation techniques
Requirements reviews Systematic manual analysis of the requirements
Prototyping Using an executable model of the system to check requirements.
Test-case generation
Developing tests for requirements to check testability
Automated consistency analysis Checking the consistency of a structured requirements description
8/11/2019 Lecture 02 RE Process
13/49
EngineeringDivision
,ThePennsylvaniaStateUniversity
13
SWENG 580: Advanced Software Engineering
Requirements management
Requirements management is the process of managing changingrequirements during the requirements engineering process and
system development
Requirements are inevitably incomplete and inconsistent New requirements emerge during the process as business needs change and a better
understanding of the system is developed Different viewpoints have different requirements and these are often contradictory
S G S f
8/11/2019 Lecture 02 RE Process
14/49
EngineeringDivision
,ThePennsylvaniaStateUniversity
14
SWENG 580: Advanced Software Engineering
Requirements change
The priority of requirements from different viewpoints changes duringthe development process
System customers may specify requirements from a business
perspective that conflict with end-user requirements
The business and technical environment of the system changes
during its development
SWENG 580 Ad d S ft E i i
8/11/2019 Lecture 02 RE Process
15/49
EngineeringDivision
,ThePennsylvaniaStateUniversity
15
SWENG 580: Advanced Software Engineering
Requirements evolution
Initialunderstanding
of problem
Changedunderstanding
of problem
Initial
Requirements
Changed
Requirements
Time
SWENG 580 Ad d S ft E i i
8/11/2019 Lecture 02 RE Process
16/49
EngineeringDivision
,ThePennsylvaniaS
tateUniversity
16
SWENG 580: Advanced Software Engineering
Enduring and volatile requirements
Enduring requirements. Stable requirements derived from the coreactivity of the customer organization. E.g. a hospital will always have
doctors, nurses, etc. May be derived from domain models
Volatile requirements. Requirements which change during
development or when the system is in use. In a hospital,
requirements derived from health-care policy
SWENG 580 Ad d S ft E i i
8/11/2019 Lecture 02 RE Process
17/49
EngineeringDivision
,ThePennsylvaniaS
tateUniversity
17
SWENG 580: Advanced Software Engineering
Requirements management planning
During the requirements engineering process, you have to plan: Requirements identification
How requirements are individually identified
A change management process
The process followed when analyzing a requirements change
Traceability policies
The amount of information about requirements relationships that is maintained
CASE tool support
The tool support required to help manage requirements change
SWENG 580 Ad d S ft E i i
8/11/2019 Lecture 02 RE Process
18/49
EngineeringDivision
,ThePennsylvaniaS
tateUniversity
18
SWENG 580: Advanced Software Engineering
Traceability
Traceability is concerned with the relationships betweenrequirements, their sources and the system design Source traceability
Links from requirements to stakeholders who proposed these requirements
Requirements traceability
Links between dependent requirements
Design traceability
Links from the requirements to the design
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
19/49
EngineeringDivision
,ThePennsylvaniaS
tateUniversity
19
SWENG 580: Advanced Software Engineering
Traceability matrix
Req. id 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2
1.1 U R
1.2 U R U
1.3 R R
2.1 R U U
2.2 U
2.3 R U3.1 R
3.2 R
8/11/2019 Lecture 02 RE Process
20/49
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
21/49
EngineeringDivision
,ThePennsylvaniaS
tateUniversity
21
SWENG 580: Advanced Software Engineering
Joint application development
Joint application design (JAD) is a process whereby highlystructured group meetings or mini-retreats involving system users,
system owners, and analysts occur in a single room for an extended
period of time (four to eight hours per day, anywhere from one day to
a couple weeks).
JAD-like techniques are becoming increasingly common in systems planning andsystems analysis to obtain group consensus on problems, objectives, and
requirements.
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
22/49
EngineeringDivision
,ThePennsylvaniaS
tateUniversity
22
SWENG 580: Advanced Software Engineering
Joint application design participants
Sponsor (top management, final say) Leader (facilitator, independent)
Users and Managers (requirements, business rules)
Scribe(s)
IS staff
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
23/49
EngineeringDivision
,ThePennsylvaniaS
tateUniversity
23
SWENG 580: Advanced Software Engineering
Joint application design sessions
Most JAD sessions span a three- to five-day time period andoccasionally last up to two weeks.
The success of any JAD session is dependent upon proper planning
and effectively carrying out that plan.
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
24/49
EngineeringDivision
,ThePennsylvaniaS
tateUniversity
24
SWENG 580: Advanced Software Engineering
Planning the JAD sessions
Before planning a JAD session, the analyst and sponsor must: Determine the scope of the project
It is also important that the high-level requirements and expectations of each JAD
session is determined.
Ensure that the sponsor is willing to commit people, time, and other resources to effort.
Planning for a JAD session involves three steps: Selecting location.
Selecting participants.
Preparing agenda.
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
25/49
EngineeringDivision
,ThePennsylvaniaS
tateUniversity
25
SWENG 580: Advanced Software Engineering
Room layout for JAD session
41' - 0"
30'-0"
Flipchart
IS Professionals
&
Other Observers
Users
and
Managers
JAD
Leader
Scribe
Workstation Printer
BlackboardOverhead Projector
Computer
Projection
Device
Food & Refreshments
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
26/49
EngineeringDivision,
ThePennsylvaniaS
tateUniversity
26
SWENG 580: Advanced Software Engineering
Selecting participants
Sponsor, analysts and managers select a leader. Leader may be in-house or contracted in.
One or more scribes must also be selected. Normally selected from the IS staff
IS Staff are selected from the development team(s)
Analyst and managers must select individuals from the usercommunity. Should be knowledgeable about their business area and able to articulate it.
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
27/49
EngineeringDivision,
ThePennsylvaniaS
tateUniversity
27
SWENG 580: Advanced Software Engineering
Conducting a JAD session
Session begins with brief overview of agenda and objectives. Leader should follow these guidelines:
Stick to agenda.
Stay on schedule (agenda topics are allotted specific time).
Ensure scribe is able to take notes.
Avoid technical jargon. Resolve conflicts (try not to defer).
Encourage group consensus.
Encourage user and management participation without allowing individuals to
dominate the session.
Make sure that attendees abide by the established ground rules.
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
28/49
EngineeringDivision,
ThePennsylvaniaS
tateUniversity
28
SWENG 580: Advanced Software Engineering
JAD document
The end product of a JAD session is typically a formal writtendocument. Essential in confirming the specifications agreed upon during the session(s) to all
participants.
Content and organization of specification obviously dependent on objectives of
session.
Analyst may choose to provide different set of specifications to different participantsbased upon their role.
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
29/49
EngineeringDivision,
ThePennsylvaniaS
tateUniversity
29
SWENG 580: Advanced Software Engineering
Benefits of JAD
An effectively conducted JAD session offers the following benefits: JAD actively involves users and management in the development project (encouraging
them to take ownership in the project).
JAD reduces the amount of time required to develop systems.
When JAD incorporates prototyping as a means of confirming requirements and
obtaining design approvals, benefits of prototyping are realized
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
30/49
EngineeringDivision,
ThePennsylvaniaS
tateUniversity
30
SWENG 580: Advanced Software Engineering
Quality function deployment
a method for developing a design quality aimed at satisfying theconsumer and then translating the consumers demand into design
targets and major quality assurance points to be used throughout the
production phase
(Akao, 1990)
Provides a structure for ensuring that customers wants and needare carefully heard, then directly translated into a companys internal
technical requirementsfrom analysis through implementation to
deployment.
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
31/49
EngineeringDivision,
ThePennsylvaniaS
tateUniversity
31
SWENG 580: Advanced Software Engineering
Voice of customer
What customers want and need from the product. Heard directly from customers and stated in their words, as much as
possible.
Forms basis for all analysis, design and development activities, to
ensure that products are not developed from only the voice of the
engineer, nor are they technology-driven
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
32/49
EngineeringDivision,
ThePennsylvaniaS
tateUniversity
32
g g
Background of QFD
First introduced by Yoji Akao in 1966. Applied to manufacturing, heavy industry and systems engineering
at first.
Applied to software systems by IBM, DEC, HP, AT&T and Texas
Instruments
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
33/49
EngineeringDivision,
ThePennsylvaniaS
tateUniversity
33
g g
QFD process (1)
The basic idea of QFD is to construct relationship matrices betweencustomer needs, technical requirements, priorities and (if needed)
competitor assessment.
To achieve this the following process is prescribed:1. Identify stakeholdersattributes or requirements
2. Identify technical features of the requirements3. Relate the requirements to the technical features
4. Conduct an evaluation of competing products
5. Evaluate technical features and specify a target value for each feature
6. Prioritize technical features for development effort.
8/11/2019 Lecture 02 RE Process
34/49
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
35/49
EngineeringDivision,
ThePennsylvaniaS
tateUniversity
35
g g
Benefits of QFD
Improves user involvement Improves management support and involvement
Shortens the development lifecycle
Improves project development
Supports team involvement
Structures communication processes
Provides a preventive tool for improving quality
Avoids loss of information
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
36/49
EngineeringDivision,
ThePennsylvaniaS
tateUniversity
36
Designer as apprentice
A new computer system changes how its customers work.Designing such a system requires intimate knowledge of customers'
work and motives to ensure that the system supports them well. The
creation of a new system implicitly means designing the new work
practice it will supportThe fundamental problem in the relationship
between customers and designers is to enable learning: how dodesigners learn enough about customers' work to design well?
What kind of relationship allows customers to impart deep
knowledge about their work?
Beyer & Holtzblatt
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
37/49
EngineeringDivision,
ThePennsylvaniaS
tateUniversity
37
Apprenticeship
The relationship between master craftsman and apprentice standsout as a useful model.
The apprentice learns a skill from the master just as we want the
designer to learn about the customers work from the customer.
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
38/49
EngineeringDivision,
ThePennsylvaniaS
tateUniversity
38
Rationale
The critical aspects of the relationship are: Teaching ability is not needed
Seeing the work reveals what matters
Seeing the work reveals details
Seeing the work reveals structure
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
39/49
EngineeringDivision,
ThePennsylvaniaS
tateUniversity
39
Teaching ability is not needed
Customers cannot talk about their work effectively, but can talkabout it as it unfolds.
Don't have to work out the best way to present it, or the motives;
they just explain what theyre doing.
"I'm entering edits from my marked up copy here... I'm working in200% magnification so I can really see how things line up. It doesn't
matter that I can't see all the text in this magnification because I'm
not checking for continuity or natural flow of words; I'll do that in
another pass later..."
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
40/49
EngineeringDivision,
ThePennsylvaniaS
tateUniversity
40
Seeing the work reveals what matters
People are not aware of everything they do and sometimes why theydo it.
Some actions are result of years of experience and have subtle
reasons; others are habit and no longer have a valid justification.
The presence of an apprentice provides the opportunity for the
master (customer) to think about the activities and how they cameabout.
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
41/49
EngineeringDivision,
ThePennsylvaniaS
tateUniversity
41
Seeing the work reveals details
Unless we are performing a task it is difficult to be detailed indescribing it.
True in most cases, but especially true in decision-making. Often predicated on many issues.
Tendency to generalize and group together similar examples; but miss important
detail.
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
42/49
EngineeringDivisio
n,
ThePennsylvaniaS
tateUniversity
42
Seeing the work reveals structure
Patterns of working are not always obvious to the worker. An apprentice learns the strategies and techniques of work by
observing multiple instances of a task and forming an understanding
of how to do it themselves, incorporating the variations.
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
43/49
EngineeringDivisio
n,
ThePennsylvaniaS
tateUniversity
43
But the designer is not an apprentice!
Apprentices want to know how to do the work, designers want to findout what a system might do to support work. So, the designer: must be responsible for seeing work structure
must articulate their understanding
is trying to improve the work
has specific focus
8/11/2019 Lecture 02 RE Process
44/49
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
45/49
EngineeringDivisio
n,
ThePennsylvaniaS
tateUniversity
45
Articulate their understanding
The designer doesnt demonstrate their understanding like anapprentice so isnt corrected when the their understanding is
wrongmust feedback to the customer instead.
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
46/49
EngineeringDivisio
n,
ThePennsylvaniaS
tateUniversity
46
Trying to improve the work
An apprentice is not expected to improve the process, the designeris.
If the designer has an idea for improving the process, this must be
fed back to the customer immediately (at the time).
Both customer and designer learn:
Customer learns what may be possible Designer expands understanding of the work (if the idea is shot down!)
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
47/49
EngineeringDivisio
n,
ThePennsylvaniaS
tateUniversity
47
Specific focus
The apprentice is there to learn whatever the master knows. The designer is there to address specific needs.
Must guide customer in talking about and demonstrating those parts of the work
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
48/49
EngineeringDivisio
n,
ThePennsylvaniaS
tateUniversity
48
Key points
RE is the process of eliciting, documenting, analyzing, validating andmanaging requirements
Many approaches exist, some more complete than others.
Crucial that there is a defined approach and that documentation
exists for each stage.
Documentation can range from high-level abstract statementsthrough psuedocode-like specifications to formal logics or models.
The elicitation process must take into account many disparate skills:
compsci, engineering, philosophy, social science.
Always striving to gather complete, precise and detailed
specifications of system requirements
SWENG 580: Advanced Software Engineering
8/11/2019 Lecture 02 RE Process
49/49
EngineeringDivisio
n,
ThePennsylvaniaS
tateUniversity
References
General: I. Sommerville, Software Engineering, Addison-Wesley, 6th Ed.
JAD: J. Whitten & L. Bentley, Systems Analysis & Design Methods, McGraw-Hill, 4th Ed.
QFD:
S Haag, MK Raja & LL Schkade, Quality Function Deployment Usage in SoftwareDevelopment, Communications of the ACM, Jan 1996, pp41-49.
Y Akao, Ed. Quality Function Deployment, Productivity Press, Cambridge, MA, 1990.
T Tran & JS Sherif, QFD: An Effective Technique for Requirements Acquisition and
Reuse, Proc. 2nd IEEE Int. Software Engineering Standards Symp., 1995.
(ISESS'95), pp 191200.
Designer as Apprentice: H Beyer & K Holtzblatt, "Apprenticing with the Customer: A Collaborative Approach to
Requirements Definition ," Communications of the ACM, May 1995.