Software Project

Management

-Srini

Objectives

Requirements Engineering tasks

Requirements management

Exercise - 1

Identify all the requirements for designing a

summer camp activity

Existing problems
What

are the problems with our

current requirement practices?

Understanding problem
Recording requirements in a disorganized
fashion
Little time spent on verification
Change not handled properly
Not able to establish a strong foundation
for development

Requirements
What

does the customer actually

means?
What delights the customer?
What should the software actually do
and how?
How to communicate to customer and
obtain confirmation?

Requirements Key
factors
Involve

the stakeholders and domain

experts
Document every aspect
Definition of clear boundary and
scope is essential
Do not rely on one source of
information
Understand the problem and its
underlying issues unambiguously

Requirements Engineering
helps

software engineers better

understand
the problems they are trying to solve
produce a written understanding of the
customer's problem.
begins during the software engineering
communication activity and continues
into the
modeling activity

Requirements Engineering
The

context of software work to be done

Basic needs that would cover design
and construction
The priority order in which the work
needs to be completed
The information, function and behaviour
of the system and the relative design

Types of Requirements
User requirements
Statements in natural language plus diagrams of the
services the system provides and its operational
constraints. Written for the customers.
System requirements
A structured document setting out detailed
descriptions of
the systems functions, services and operational
constraints. Defines what should be implemented so
may
be part of a contract between client and contractor.

User requirement

Should describe functional and nonfunctional

requirements in such a way that they are
understandable by system users who do not
have detailed technical knowledge.
User requirements are defined using natural
language, tables and diagrams as these can
be understood by all the users

System requirement
More

detailed specifications of system

functions,
services and constraints than user
requirements.
They are intended to be a basis for
designing the
system.
They may be incorporated into the
system contract.
System requirements may be defined or
illustrated using system models

Functional requirements
Describe functionality or system services.
Depend on the type of software,
expected users and the type of system
where the software is used.
Functional user requirements may be
high-level
statements of what the system should do
but
functional system requirements should
describe the system services in detail.

Non functional requirements

Product

requirement

The user interface shall be implemented

as a simple HTML without frames or Java
applets

Organization

The system development process and

deliverables will pertain to CMM level 3
standard

External

requirement

requirement

The system shall not disclose any

personal information about the customers
apart from the name and reference
number to the operators of the system

Domain requirements
Derived

from the application domain

and describe system characteristics
and features that reflect the domain.
Domain requirements be new
functional requirements, constraints
on existing requirements or define
specific computations.

If

domain requirements are not

satisfied, the system may be
unworkable

Requirements Engineering
Tasks
Requirements
Requirements
Requirements
Requirements
Requirements
Requirements
Requirements
-

Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Management

All above steps are not sequential, but are iterative

Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management

Inception Task

During inception, the requirements engineer asks a set of

questions to establish

A basic understanding of the problem

The people who want a solution
The nature of the solution that is desired
The effectiveness of preliminary communication and collaboration
between the customer and the developer

Through these questions, the requirements engineer needs

to

Identify the stakeholders

Recognize multiple viewpoints
Work toward collaboration
Break the ice and initiate the communication

Requirements Elicitation
Fact
-

Finding

What are the various sources of the

requirements
Who are the customers or system users
Does similar competition exist in the industry

Information
-

Interviews, Customer supplied documents

Surveys, Analysis, wish list from each sources
Check for feasibility

Information
-

gathering
integration

Integrate technical and non-technical

requirements
Remove inconsistencies, conflicts
Check for feasibility

Requirements Elicitation
-

List of objectives which are consistent in

nature
List of issues, problems and threats
faced in the current scenario
Assumptions list, validated from
customers
Possible solutions
Specification given by customer
Defined input to initiate the requirement
analysis and project planning activities

Requirements Elicitation
Problems of scope
-

Avoid any ambiguity and define the

system boundary clearly
Discuss the boundary and scope with
the customer

Requirements Elicitation
Problems of understanding
-

Use visual models like UML, Screen shots

Prototyping of GUI and system components
Use of project glossary
Use non technical words in specification
Follow structural development from
business Use case development to system
use case development

Requirements Elicitation
Problems of change
-

Quick review and feedback from all the

stakeholders, when change is needed in
the system
Proper change management procedure
Proper impact analysis of the change with
respect to existing customers
Structured configuration management
Changes in all documents with respect to
the new change

Requirements Elicitation
Elicitation

may be accomplished by

Collaborative requirement gathering

FAST (Facilitated Application Specification
Technique)
QFD (Quality Function Deployment)

Basic Guidelines of Collaborative

Requirements Gathering

Meetings are conducted and attended by both software

engineers, customers, and other interested stakeholders
Rules for preparation and participation are established
An agenda is suggested that is formal enough to cover
all important points but informal enough to encourage
the free flow of ideas
A "facilitator" (customer, developer, or outsider)
controls the meeting
A "definition mechanism" is used such as work sheets,
flip charts, wall stickers, electronic bulletin board, chat
room, or some other virtual forum
The goal is to identify the problem, propose elements of
the solution, negotiate different approaches, and specify
a preliminary set of solution requirements

Quality Function Deployment

This is a technique that translates the needs of the customer

into technical requirements for software
It emphasizes an understanding of what is valuable to the
customer and then deploys these values throughout the
engineering process through functions, information, and tasks
Originally developed in Japan in 1970s and used in a shipyard
It identifies three types of requirements

Normal requirements: These requirements are the objectives and

goals stated for a product or system during meetings with the
customer
Expected requirements: These requirements are implicit to the
product or system and may be so fundamental that the customer
does not explicitly state them
Exciting requirements: These requirements are for features that go
beyond the customer's expectations and prove to be very
satisfying when present

Quality Function Deployment

Function

deployment is used to
determine the value of each function
that is required for the system
Information deployment identifies both
data objects and events that the
system must consume and produce
Task deployment examines the
behaviour of the system or the product
within the context of the environment

Elicitation Work Products

The work products will vary depending on the system, but should
include one or more of the following items

A statement of need and feasibility

A bounded statement of scope for the system or product
A list of customers, users, and other stakeholders who
participated in requirements elicitation
A description of the system's technical environment
A list of requirements (organized by function) and the
domain constraints that apply to each
A set of preliminary usage scenarios (in the form of use
cases) that provide insight into the use of the system or
product under different operating conditions
Any prototypes developed to better define requirements

Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management

Requirements Elaboration

Question why do we need objective X?

- Room for future evolution of requirements
- Prepare visual models

Elaboration Task

During elaboration, the software engineer takes the

information obtained during inception and elicitation
and begins to expand and refine it
Elaboration focuses on developing a refined technical
model of software functions, features, and constraints
It is an analysis modeling task

Use cases are developed

Domain classes are identified along with their attributes and
relationships
State machine diagrams are used to capture the life on an
object

The end result is an analysis model that defines the

functional, informational, and behavioral domains of the
problem

Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management

Negotiation Task

During negotiation, the software engineer reconciles the

conflicts between what the customer wants and what
can be achieved given limited business resources
Requirements are ranked (i.e., prioritized) by the
customers, users, and other stakeholders
Risks associated with each requirement are identified
and analyzed
Rough guesses of development effort are made and
used to assess the impact of each requirement on
project cost and delivery time
Using an iterative approach, requirements are
eliminated, combined and/or modified so that each
party achieves some measure of satisfaction

Requirements
Specification

Statement of needs and objectives

Classified requirements
Prioritized requirements
Each specification must have a unique
number for later traceability
Template at organization level for
Software requirement specification
(SRS) or Requirements Specification
(RS)

Requirements Specification
Requirements documents should be
- unambiguous
- complete
- verifiable
- consistent
- modifiable
- traceable
- prioritized
- usable

Requirements Documentation
Typical contents of SRS / RS
- Overall Description
- Assumptions, constraints and
dependencies
- System requirements
Functionality
- Performance
- Usability
- Reliability
- Availability
- Interfaces
-

- Portability
- Documentation
- Licensing

Requirements Documentation
Typical contents of Use case description
- Use Case Diagram
- Brief description of Use Case
- Pre-condition
- Basic flow of events
- Alternate flow of events
- Post Conditions
- Extension Points
- Special requirements with regard to
-

Performance
Usability

Specification Task

A specification is the final work product produced by the

requirements engineer
It is normally in the form of a software requirements
specification
It serves as the foundation for subsequent software
engineering activities
It describes the function and performance of a
computer-based system and the constraints that will
govern its development
It formalizes the informational, functional, and
behavioral requirements of the proposed software in
both a graphical and textual format

Typical Contents of a Software

Requirements Specification

Requirements

Qualification provisions to ensure each requirement

has been met

Required states and modes

Software requirements grouped by capabilities (i.e.,
functions, objects)
Software external interface requirements
Software internal interface requirements
Software internal data requirements
Other software requirements (safety, security, privacy,
environment, hardware, software, communications,
quality, personnel, training, logistics, etc.)
Design and implementation constraints
Demonstration, test, analysis, inspection, etc.

Requirements traceability

Trace back to the system or subsystem where each

requirement applies

Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management

Requirements Validation
Reviews

should be formal and documented

Reviews should be both internal and
external
Frequently submit artifact to customer /end
user for feedback
Joint reviews are useful to promote shared
understanding
Key to success is activity, review,validate,
rework, re-inspection and revalidation
Reviewed requirement form the basis for
detailed estimation, planning and other
work products

Requirements Validation
-

Validate requirements which are consistent

Check if all higher level goals are being
satisfied
Check if there are any kind of conflicts
between requirements
Check if requirements are complete, feasible
and verifiable
Check if impact on
cost,schedule,functionality and risks
understood
Understand requirements to the lowest level
Check if all groups involved in the project
understand the requirements equally

Questions to ask when

Validating Requirements
(continued)

Do any requirements conflict with other

requirements?
Is each requirement achievable in the technical
environment that will house the system or
product?
Is each requirement testable, once implemented?

Approaches: Demonstration, actual test, analysis, or

inspection

Does the requirements model properly reflect the

information, function, and behavior of the system
to be built?
Has the requirements model been partitioned in
a way that exposes progressively more detailed
information about the system?

Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management

Requirements Management Task

During requirements management, the project team

performs a set of activities to identify, control, and track
requirements and changes to the requirements at any
time as the project proceeds
Each requirement is assigned a unique identifier
The requirements are then placed into one or more
traceability tables
These tables may be stored in a database that relate
features, sources, dependencies, subsystems, and
interfaces to the requirements
A requirements traceability table is also placed at the
end of the software requirements specification

Requirements Management
Goals

Maintain a common understanding between

customer and developers throughout life cycle
Establish baseline for development
Manage scope

Techniques

Document all requirements before the next phase

Review and analyze system impact upon initial
creation and subsequent change requests
Combine with configuration management
techniques
Maintain Traceability matrices

Project Activities

Prototyping
The

model of the software to be built

Helps in customer and developer
assessment
Types

Throwaway
Evolutionary

Software Engineering
practice
What

is software engineering practice?

Software Engineering
Contains

a collection of concepts,
principles, methods and tools that is
used by development team
Transforms a haphazard unfocused
approach into something that is more
organized, effective and more likely to
achieve success

Problem solving
Understand

the problem (Till

requirements analysis)
Find a solution and plan (Modeling
and design)
Carry out the plan (Construction
and code generation)
Examine the results (Testing and
quality assurance)