SRE –

What, Who and Why ?

Lecture 02
 Software Requirements - 1
Requirements are…a specification of what should be implemented.
They are descriptions of how the system should behave, or of a
system property or attribute. They may be a constraint on the
development process of the system.

The IEEE Standard Glossary of Software Engineering Terminology

(1990) defines a requirement as:
•
A condition or capability needed by a user to solve a problem or achieve
an objective.
•
A condition or capability that must be met or possessed by a system or
system component to satisfy a contract, standard, specification, or other
formally imposed document.
Software Requirements - 2

A complete description of what the software system

will do without describing how it will do it is
represented by the software requirements

Software requirements are complete specification of

the desired external behavior of the software system to
be built
Software Requirements - 3
Software requirements can be:
●
Part of the bid of contract
●
The contract itself
●
Part of the technical document, which describes a product

Software requirements can be:

Abstract statements of services and/or constraints Detailed
mathematical functions
What are NOT Requirements
Requirements do not include:
●
Design or Implementation details (other than known constraints)
●
Project planning information, or testing information.
●
Development environment requirements, schedule or budget
limitations
●
Need for a tutorial to help new users get up to speed, or
requirements for releasing a product and moving it into the
support environment.

These are project requirements but not product requirements.

Separate such items from the requirements so that the
requirements activities can focus on understanding what the team
intends to build.
Levels of Requirements
Software Requirements Engineering

Requirements engineering - is the process which enables us to

systematically determine the requirements of a software product

Requirements engineering - refers to the process of formulating,

documenting and maintaining software requirements
A principal - A Domain
Requirement Development
Requirements development can be further subdivided into elicitation,
analysis, specification, and validation
• Identifying the product's expected user classes
• Eliciting needs from individuals who represent each user class
• Understanding user tasks and goals and the business objectives with which those tasks
align
• Analyzing the information received from users to distinguish their task goals from functional
requirements, nonfunctional requirements, business rules, suggested solutions, and
extraneous information
• Allocating portions of the top-level requirements to software components defined in the
system architecture
• Understanding the relative importance of quality attributes
• Negotiating implementation priorities
• Translating the collected user needs into written requirements specifications and models
• Reviewing the documented requirements to ensure a common understanding of the users'
stated requirements and to correct any problems before the development group accepts
them
Requirements Management
• Defining the requirements baseline (a snapshot in time representing
the currently agreed-upon body of requirements for a specific release)
• Reviewing proposed requirements changes and evaluating the likely
impact of each change before approving it
• Incorporating approved requirements changes into the project in a
controlled way
• Keeping project plans current with the requirements
• Negotiating new commitments based on the estimated impact of
requirements changes
• Tracing individual requirements to their corresponding designs,
source code, and test cases
• Tracking requirements status and change activity throughout the
project
Line differentiating RD and RM
Factors for Bad Requirements
●
Insufficient User Involvement
●
Creepy User Requirements
●
Ambiguous Requirements – Keep it Simple, Clear and Concise
●
Gold Plating
●
Minimal Specification
●
Overlooked User Classes – identify all Important user
classes
●
Inaccurate Planning
Benefits of High-Quality Requirements
●
Fewer requirements defects
●
Reduced development rework
●
Fewer unnecessary features
●
Lower enhancement costs
●
Faster development
●
Fewer miscommunications
●
Reduced scope creep
●
Reduced project chaos
●
More accurate system-testing estimates
●
Higher customer and team member satisfaction
What Excellent Requirements have ?
●
Complete
●
Correct
●
Feasible
●
Necessary
●
Prioritized
●
Unambiguous
●
Verifiable
●
Consistent
●
Modifiable - compatibility
●
Traceable
Requirements – Customer's Perspective
Who is a Customer ?

A customer is an individual or organization who derives either direct or

indirect benefit from a product.

Software customers include those project stakeholders who request,

pay for, select, specify, use, or receive the output generated by a
software product.
Customer-Development Partnership - 1
Excellent software products are the result of a well-executed
design based on excellent requirements. High-quality
requirements result from effective communication and
collaboration between developers and customers—a
partnership
A collaborative effort can work only when all parties involved
know what they need to be successful and when they
understand and respect what their collaborators need to be
successful.
As project pressures rise, it's easy to forget that all stakeholders
share a common objective – This is not an Easy road to travel
Customer-Development Partnership - 2
Requirements Bill of Rights (of Customer):
●
Expect analysts to speak your language.
●
Expect analysts to learn about your business and your objectives for the system.
●
Expect analysts to structure the information you present during requirements
elicitation into a written software requirements specification.
●
Have analysts explain all work products created from the requirements process.
●
Expect analysts and developers to treat you with respect and to maintain a
collaborative and professional attitude throughout your interactions.
●
Have analysts and developers provide ideas and alternatives both for your
requirements and for implementation of the product.
●
Describe characteristics of the product that will make it easy and enjoyable to use.
●
Be given opportunities to adjust your requirements to permit reuse of existing
software components.
●
Receive good-faith estimates of the costs, impacts, and trade-offs when you
request a change in the requirements.
●
Receive a system that meets your functional and quality needs, to the extent that
those needs have been communicated to the developers and agreed upon.
Customer-Development Partnership - 3
Requirements Bill of Responsibilities (of Customer):
●
Educate analysts and developers about your business and define business jargon.
●
Spend the time that it takes to provide requirements, clarify them, and iteratively
flesh them out.
●
Be specific and precise when providing input about the system's requirements.
●
Make timely decisions about requirements when requested to do so.
●
Respect a developer's assessment of the cost and feasibility of requirements.
●
In collaboration with the developers, set priorities for functional requirements,
system features, or use cases.
●
Review requirements documents and evaluate prototypes.
●
Communicate changes to the requirements as soon as you know about them.
●
Follow the development organization's process for requesting requirements
changes.
●
Respect the processes the analysts use for requirements engineering.
Sign-Off ?
- What - Core of Customer-Developer partnership
– Reaching agreement on the requirements
– Its not a weapon, rather a Milestone
– Baseline for requirements
– A way to freeze incoming requirements
- Why - help managers plan and prioritize requirements
– Customer management is confident that the project scope won't
explode out of control
– User representatives have confidence that development will work
with them to deliver the right system
– Development management has confidence because the
development team has a business partner who will keep the project
focused on achieving its objectives
– 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.
Best Practices in Requirements Engineering - 1
1. Knowledge
1. Train requirements Analysts
1. Bridges communication between Customer and Dev.
Stakeholders
2. Former developer or subject matter experts – No
3. Create collaborative environment
2. Educate user representative and Managers about requirements
Engineering
3. Train developers in application domain concepts
4. Create project Glossary
Best Practices in Requirements Engineering - 2
2. Requirements Elicitation

●
Define a requirements development process
●
Write a vision and scope document
●
Identify user classes and their characteristics
●
Establish focus groups of typical users
●
Identify system events and responses
●
Hold facilitated elicitation workshops.
●
Examine problem reports of current systems for requirement ideas
●
Reuse requirements across projects
Best Practices in Requirements Engineering - 3
3. Requirements Analysis

●
Draw a context diagram
●
Analyze requirement feasibility
●
Prioritize the requirements
●
Model the requirements
●
Create a data dictionary – for consistent data definition across teams in
project
●
Allocate requirements to subsystems
Best Practices in Requirements Engineering - 4
4. Requirements Specification

●
SRS – adopt a scalable template (IEEE)
●
Identify sources of requirements
●
Uniquely label each requirement.
●
Record business rules
●
Specify quality attributes
Best Practices in Requirements Engineering - 5
5. Requirements Validation

●
Inspect requirements documents
●
Formal Inspection
●
Informal reviews
●
Test the requirements
●
Derive functional test cases for requirement and walk through with
customers
●
Define acceptance criteria
●
User reviews – customer based acceptance criteria
Best Practices in Requirements Engineering - 6
6. Requirements Management

●
Change control process and Change control Board (CCB)
●
Perform requirements-change impact analysis
●
Establish a baseline and control versions of requirements documents
●
Maintain a history of requirements changes
●
Track the status of each requirement.
●
Use a requirements management tool – DOORs etc
●
Create a requirements traceability matrix
Best Practices in Requirements Engineering - 7
7. Requirements Development Process

-
Best Practices in Requirements Engineering - 8
8. Project Management

●
Select an appropriate software development life cycle
●
Base project plans on requirements.
●
Renegotiate project commitments when requirements change
●
Document and manage requirements-related risks
●
Track the effort spent on requirements engineering
●
Review lessons learned regarding requirements on other projects
- Questions ?