Requirements

Engineering
Lecture 06
National University FAST
October 03, 2015, 18:00 21:00

Sign Of
Dont use sign of as a weapon
Use it as a project milestone, with a clear,

shared understanding of the activities that

lead to sign of and its implications for future
changes
More important than the sign of ritual is the
concept of establishing a baseline of the
requirements agreement, a snapshot of it at a
point in time

Sign Of
The subtext of a signature on a requirements

specification sign of page should therefore

read something like this
I agree that this document represents our best

understanding of the requirements for this

project today and that the system described will
satisfy our needs.
I agree to make future changes in this baseline
through the projects defined change process.
I realize that approved changes might require
us to renegotiate the cost, resource, and
schedule commitments for this project.
3

Sign Of
After the analyst defines the baseline, he places

the requirements under change control

This allows the team to modify the projects
scope when necessary in a controlled way that
includes analyzing the impact of each proposed
change on the schedule and on other project
success factors
If customers are afraid that they wont be able to
make changes after they approve the SRS, they
might delay the approval, which contributes to
the dreaded trap of analysis paralysis
4

Sign Of
Sealing the initial requirements development

activities with such an explicit agreement

helps you forge a collaborative customerdevelopment partnership on the way to
project success

Sign Of
A meaningful baselining process gives all the

major stakeholders confidence in the following

ways:
Customer management is confident that the

project scope wont explode out of control, because

customers manage the scope change decisions
User representatives have confidence that
development will work with them to deliver the
right system, even if the representatives didnt
think of every requirement before construction
began
6

Sign Of
A meaningful baselining process gives all the

major stakeholders confidence in the following

ways:
Development management has confidence

because the development team has a business

partner who will keep the project focused on
achieving its objectives and will work with
development to balance schedule, cost,
functionality, and quality
Requirements analysts are confident because
they know that they can manage changes to the
project in a way that will keep chaos to a minimum
7

Good Practices for Requirements

Engineering
Knowledge
Train requirements analysts
Educate user reps and managers about

requirements
Train developers in application domain
Create a glossary

Good Practices for Requirements

Engineering
Elicitation
Define requirements development process
Define vision and scope
Identify user classes
Select product champions
Establish focus groups

Good Practices for Requirements

Engineering
Elicitation
Identify use cases
Identify system events and responses
Hold facilitated elicitation workshops
Observe users performing their jobs
Examine problem reports
Reuse requirements

10

Good Practices for Requirements

Engineering
Analysis
Draw context diagram
Create prototypes
Analyze feasibility
Prioritize requirements
Model the requirements
Create a data dictionary
Allocate requirements to subsystems
Apply Quality Function Deployment
11

Good Practices for Requirements

Engineering
Specification
Adopt SRS template
Identify sources of requirements
Uniquely label each requirement
Record business rules
Specify quality attributes

12

Good Practices for Requirements

Engineering
Validation
Inspect requirements documents
Test the requirements
Define acceptance criteria

13

Good Practices for Requirements

Engineering
Requirements Management
Define change control process
Establish change control board
Perform change impact analysis
Baseline and control versions of requirements
Maintain change history
Track requirements status
Measure requirements volatility
Use a requirements management tool
Create requirements traceability matrix
14

Good Practices for Requirements

Engineering
Project Management
Select appropriate life cycle
Base plans on requirements
Renegotiate commitments
Manage requirements risks
Track requirements efort
Review past lessons learned

15

Implementing Requirements Engineering Good Practices

Impact

Difficulty
High

Medium

Low

High

Define requirements
development process
Base plans on
requirements
Renegotiate
commitments

Identify use cases

Specify quality attributes
Prioritize requirements
Adopt SRS template
Define change-control process
Establish CCB
Inspect requirements
documents
Allocate requirements to
subsystems
Record business rules

Train developers in application

domain
Define vision and scope
Identify user classes
Draw context diagram
Identify sources of
requirements
Baseline and control versions
of requirements

Mediu
m

Educate user reps and

managers about
requirements
Model the requirements
Manage requirements
risks
Use a requirements
management tool
Create requirements
traceability matrix
Hold facilitated
elicitation workshops

Train requirements analysts

Select product champions
Establish focus groups
Create prototypes
Define acceptance criteria
Perform change impact
analysis
Select appropriate life cycle

Analyze feasibility
Create a glossary
Create a data dictionary
Observe users performing
their jobs
Identify system events and
responses
Uniquely label each
requirement
Test the requirements
Track requirements status
Review past lessons learned

Low

Reuse requirements
Apply Quality Function

Measure requirements
Track requirements efort

Examine problem reports

16

The Requirements
Analyst
Position
Business Analyst
Synonyms
Systems Analyst
Requirements Engineer
Requirements Manager
Analyst

17

The Requirements Analyst Role

The requirements analyst is the individual

who has the primary responsibility to gather,

analyze, document, and validate the needs of
the project stakeholders
The analyst serves as the principal conduit
through which requirements flow between the
customer community and the software
development team

18

Other
Stakehol
ders

Requirements Analysts Role

Testing
Team

User
Representa
tives

Project
Sponsor

Requirem
ents
Analyst
Project
Managem
ent Team

Developm
ent Team
19

The Requirements Analyst Role

Many other communication pathways are

used also, so the analyst isnt solely

responsible for information exchange on the
project
The analyst plays a central role in collecting
and disseminating product information,
whereas the project manager takes the lead in
communicating project information

20

The Requirements Analyst Role

Requirements analyst is a project role, not

necessarily a job title

One or more dedicated specialists could perform
the role, or it could be assigned to team members
who also have other job functions
These functions include project manager, product
manager, subject matter expert, developer, or a
user
Regardless of their other project responsibilities,
analysts must have the skills, knowledge, and
personality to perform the analyst role well
21

The Analysts Tasks

The analyst is a communication middleman,

bridging the gap between vague customer

notions and the clear specifications that guide
the software teams work
The analyst must first understand the users
goals for the new system and then define
functional and quality requirements that allow
project managers to estimate, developers to
design and build, and testers to verify the
product
22

The Analysts Tasks

Define business requirements
Identify project stakeholders and user classes
Elicit requirements
Analyze requirements
Write requirements specifications
Model the requirements
Lead requirements validation
Facilitate requirements prioritization
Manage requirements
23

Elicitation Techniques
Interviews
Facilitated requirements workshops
Document analysis
Surveys
Customer site visits

24

Elicitation Techniques
Business process analysis
Work flow and task analysis
Event lists
Competitive product analysis
Reverse engineering of existing systems
Retrospectives performed on the previous

project

25

Essential Analyst Skills

Listening skills
Interviewing and questioning skills
Analytical skills
Facilitation skills
Observational skills
Writing skills
Organizational skills
Modeling skills
Interpersonal skills
Creativity
26

Who could be an Analyst

The Former User
The Former Developer or QA Engineer
The Subject Matter Expert

27