Systems Requirements Engineering

Prof M L SaikumarInstitute of Public Enterprise

Requirements

• Requirement Analysis - Tajmahal

• Walking on water and Developing software from specifications are easy

If both are frozen

• Requirements without activity – Activity without Requirements

• Software Demo

• Fully Automated Aircraft

Why are Requirements so Important?

Software Development Cycle

• Waterfall model

• Prototyping

• Spiral model

Definition

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 Rationale for Focus on Requirements(Industry Data: 8,000 software projects)

• 53% of industry’s investment on application development projects is a casualty of cost overruns and failed projects

• Major contributing factors include: lack of user input (13%); incomplete requirements (12%); and changing requirements.

• Reducing requirements errors is the single most effective action developers can take to improve project outcomes.

• There is as much as a 2000:1 cost savings from finding errors in the requirements stage vs. in the maintenance stage of the life-cycle.

• Requirements errors are the largest class of errors typically found in a project (41-56% of errors are discovered).

• The cost of rework is typically 45% of projects.

Typical Customer and Supplier Issues and Remedies

Customer Supplier

1. Use domain experts2. Consider technology change management

Lacks subject matter expertise to address functional needs

5. Doesn’t update the statement of current user operating concepts or technology improvements

1. Emerge the high level real requirements2. Strengthen commitment/gain a “shared vision”

Doesn’t engage the client in a process to distill the real needs

4. Provides overly specific specifications

1. Take proactive steps to improve communications2. Utilize a peer review process

Doesn’t encourage and nurture more effective communication

3. Doesn’t communicate the need effectively

1. Utilize a joint team2. Meet minimum requirements

Is unwilling/unable to meet true needs within fiscal boundaries

2. Doesn’t understand what is achievable within fiscal boundaries

1. Invest more in the requirements process

2. Define the real customer needs

Doesn’t understand the customer’s need1. Doesn’t understand the real need

Remedies

Difficulties in Requirements Analysis

• For the client,– requirements are an end in, and of themselves

• For the IT professional, – requirements are a means to an end

• This is market mismatch

Difficulties in Requirements Analysis

• Insufficient time allowed

• Insufficient or inefficient review with users

• Differences of opinion

• Political twists and turns

• Lack of technical knowledge

• Inability to write well

• Lack of structured analysis techniques

Risks from Inadequate Requirements Processes

• Insufficient user involvement leads to unacceptable products

• Creeping user requirements contribute to overruns and degrade product quality

• Ambiguous requirements lead to ill-spent time and rework

• Gold-plating by developers and users adds unnecessary features

• Minimal specifications lead to missing key requirements

• Overlooking the needs of certain user classes leads to dissatisfied customers

• Incompletely defined requirements make accurate project planning and tracking impossible

M L Saikumar

Requirement Statement Characteristics

• Complete

• Correct

• Feasible

• Necessary

• Prioritized

• Unambiguous

• Verifiable

Requirement Specification Characteristics

• Complete

• Consistent

• Modifiable

• Traceable

Hierarchical Decomposition of the Requirements Engineering Domain

Requirements Engineering

Requirements Development Requirements Management

Elicitation Analysis Specification Verification

Requirements Development Activities

• Identifying the expected user classes for the product

• Eliciting needs from individuals who represent each user class

• Understanding actual user tasks and objectives

• Analyzing the information received from users

• Partitioning system-level requirements into major subsystems.

• Understanding the relative importance of quality attributes

• Negotiating implementation priorities• Translating the collected user needs into written

specifications and models• Reviewing the requirements specifications

Understanding the relative importance of quality attributes

• Negotiating implementation priorities• Translating the collected user needs into written

specifications and models• Reviewing the requirements specifications

Requirements Management Activities

• Defining the requirements baseline

• Reviewing proposed requirements

• Incorporating approved requirements changes into the project in a controlled way

• Keeping projects plans current with the requirements

• Negotiating new commitments based on the estimated impact of changed requirements

• Tracing individual requirements to their corresponding designs, source code, and test cases

• Tracking requirements status and change activity throughout the project.

Req Mgmnt Vs Req Engg• It includes all activities

that maintain the integrity and accuracy

• It includes controlling changes to the requirements baseline

• It deals with the application of the requirements in developing the system

• It deals with maintaining tractability of requirements

• It is the systematic use of principles, techniques and tools

• It deals with the evolution of requirements

• It checks the feasibility in terms of cost, time and resources

• It comes before the Req management

SW Req Engg Vs Systems Req Engg

• This is a subset of Systems RE

• It involves how the requirements to be met

• It is one of the first activity of SW development life cycle

• It ends after producing SRS document

• It includes SW and HW Requirements Engineering

• It involves in knowing what is to be accomplished by the system

• It is usually performed iteratively, alternating with system design

SW Req Engg Vs Systems Req Engg

• Technical skills are required while doing SW requirements Engg

• SWRS serves as a product validation check

• It is secondary stage of development cycle

• Focuses on Technical issues

• Technical as well as non-technical skills are required while doing Systems RE

• SRS serves as a customer validation check

• It is primary stage of development cycle

• Focuses on Functional issues

Reference

Developing the Requirements discipline Software Vs Systems

Rezine Gonzales

IEEE Software, March/April 2005, pages 59-61

Exercise

• Write down any requirements-related problems you have encountered on your current or previous classes. Identify each as a requirements development or requirements management problem. Identify the impact caused by each problem and the root cause of each problem.

• Facilitate a discussion with your team members and other stakeholders on requirements – related problems from your current or previous class, their impacts, and their root causes. Explain to the participants that they have to begin confronting these difficult issues if they ever hope to master them. Are they ready to try?

References

1. Mastering the Requirements Process Robertson & Robertson, Addison Wesley2. Software Requirements Karl E. Wiegers, Microsoft press3. User-Centered Requirements Analysis Charles F. Martin, Prentice-hall4. Writing Better Requirements

Alexander & Stevens, Addison wesley, 20025. An Introduction to Requirements Engineering

Ian K Bray, Addison wesley, 20026. Requirements Engineering Process &

Techniques Kotonya & Sommerville, John wiley, 1998

References

7. Practical Software Requirements Benjamin& Kovitz, Manning, 1999

8. Writing Effective Use Cases Alistair Cockburn, Addison Wesley, 2001

9. Patterns for Effective Use cases Adolph & Bramble, Addison wesley, 2003

10 Engineering and Managing Software RquirementsAurum, Wohlin, Springer Verlag, 2005

11 Software Requirements EngineeringThayer, Dorfman

12 Requirements by CollaborationGottesdiener, Addison Wesley

Websites

• www.requirements-engineering.org

• www.systemsguild.com/guildSite/Guild/resources.html

• www.standishgroup.com

• www.comp.lancs.ac.uk/computing/resources/re-gpg

• www.re05.org, www.re06.org, www.re07.org

• www.incose.org

• www.processimpact.com