SRE –

What, Who and Why ?

Lecture 03
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.
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.
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