Requirements Engineering CT056-3-2

Fundamentals of Requirements Engineering

Lecture 5

Topic & Structure of the lesson

Subcomponents of Requirements Engineering

Consequences of Good and Bad requirements

Attributes of requirements specifications

Good Practices of Requirements Engineering

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Learning Outcomes
By the end of this lecture, YOU should be able to:
define RE and describe activities undertaken in RE development define RE and describe activities undertaken in RE Management Identify the good RE practices within the respective subcomponents of RE development

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Key Terms you must be able to use

If you have mastered this topic, you should be able to use the following terms correctly in your assignments and exams:
RE management RE development
Elicitation Analysis Specification validation
Fundamentals of Requirements Engineering #

CT056-3-2 Requirements Engineering

Subcomponents of requirements engineering

Requirements Engineering

Requirements Development

Requirements Mgt

Elicitation

Analysis

Specification

Validation

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Requirements Development
Involves: Identifying the products expected user classes Eliciting needs from user class Understanding user tasks, goals and business objectives Analyzing user information, distinguishing task goals, functional and non-functional requirements Transforming user needs to requirements specification

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Requirements Management
Is the establishing and maintaining an agreement with the customer on the requirements for the software project The agreement is embodies in the written requirement specification Req. Mgt. Activities : Define requirements baseline Review proposed changes Incorporate approved requirements Keeping project plans Tracing individual requirements, from design to source code Tracking requirements status

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Every Projects Has Requirements

"The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to the software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later".

Fred Brooks, "No Silver Bullet :Essence and Accidents of SE", IEEE Computer,1987 Author of The Mythical Man-mon

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Consequences of bad requirements

Reworks redoing something, can cost 30 50% of total development cost (Boehm and Papaccio 1998) Requirements errors account for 70 -85% of rework cost (Leffingwell 1997) Bad requirements pose risks to project success

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Common requirements risk

Insufficient user involvement
Developers dont stress the importance of user involvement Additional requirements far exceeds what were not budgeted or planned for Requirement statements can be interpreted in many ways Developer adds functionalities which were not in the original requirements specification Outlined specs, lacking details Some users needs overlooked Vaguely defined requirements, results in optimistic estimates

Creeping User requirements Ambiguous requirements Gold plating Minimal Specification Overlooked user classes Inaccurate Planning

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Benefits of good requirements

Fewer requirements defects Reduced development reworks Fewer unnecessary features Lower enhancement costs Faster development Fewer miscommunications Reduced scope creep

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Characteristics of Excellent Requirements statements

Requirements statements must be: Complete fully describe functionality Correct accurately describe functionality to be built Feasible possible to implement, attainable Necessary really needed by the customer Prioritized implementation priority for requirements Unambiguous requirements with one single interpretation Verifiable tests can be devised or other forms verification available

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Requirements specification characteristics

Complete no missing requirements or necessary information Consistent no conflict among requirements Modifiable requirements revisions possible and history of revision maintained. Traceable traceable requirements can be linked backward to its origins and forward to the design element

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Requirements from the Customers Perspective

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Requirements from customers perspective

Who are customers?
Individuals or organization who have benefits from a product
The one who request, specify, select , use, receive outputs from a software product They provide the business requirements Effectively collaborate with developers to derive successful products Ones who sign off indicating approval of requirements

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Good Practices for RE

There are approximately 50 practices grouped into seven categories :1. Knowledge 2. Requirements Management 3. Project Management 4. Elicitation 5. Analysis 6. Specification 7. Validation

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Good Practices for RE -Knowledge

Train requirements analyst Educate user reps and manager about requirements Train developers in application domain Create a glossary

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Good Practices for RE -Req. Management

CT056-3-2 Requirements Engineering

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
Fundamentals of Requirements Engineering #

Good Practices for RE -Project Management

Select the appropriate life cycle Base plans on requirements Renegotiate commitments Manage requirements risk Track requirements efforts Review past lessons learned

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Good Practices for RE -Elicitation

CT056-3-2 Requirements Engineering

Define requirements evelopment process Define vision and scope Identify user classes Select product champions Establish focus groups Identify use case Identify system events and responses Hold facilitated elicitation workshops Observe user performing jobs Examine problem reports Reuse requirements
Fundamentals of Requirements Engineering #

Good Practices for RE -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

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Good Practices for RE -Specification

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

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

Good Practices for RE -Validation

Inspect requirements document Test the requirements Define acceptance criteria

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering

References
Software Requirements; Karl E. Wiegers; 2nd Edition; 2003

CT056-3-2 Requirements Engineering

Fundamentals of Requirements Engineering