SRE - Lec # 2

>>>>> Download Slide Here <<<<<


What's in the Slide?

SRE – What, Who and Why ?
BSEF15 (V)
Abdul Razaq Ali
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
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
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/Scope Creep
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/Gold Plating
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.
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

Questions?