week 5 - lecture 1 - fundamental of re

8/13/2019 Week 5 - Lecture 1 - Fundamental of RE

http://slidepdf.com/reader/full/week-5-lecture-1-fundamental-of-re 1/24

Requirements Engineering

CT056-3-2

Fundamentals of Requirements

EngineeringLecture 5



CT056-3-2 Requirements Engineering Fundamentals of Requirements Engineering

Topic & Structure of the lesson

• Subcomponents of Requirements Engineering

• Consequences of Good and Bad requirements

• Attributes of requirements specifications

• Good Practices 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

‹#›




Subcomponents of requirements

engineering

Requirements Engineering

Requirements

Development

Requirements Mgt

Elicitation Analysis Specification Validation

‹#›


http://slidepdf.com/reader/full/week-5-lecture-1-fundamental-of-re 8/24CT056-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 ifdone 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

‹#›



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

‹#›



Common requirements risk

• Insufficient user involvement – Developers don’t stress the importance of user involvement

• Creeping User requirements – Additional requirements far exceeds what were not budgeted or planned for

• Ambiguous requirements – Requirement statements can be interpreted in many ways

• Gold plating – Developer adds functionalities which were not in the original requirements specification

• Minimal Specification – Outlined specs, lacking details

• Overlooked user classes – Some users needs overlooked

• Inaccurate Planning – Vaguely defined requirements, results in optimistic estimates

‹#›



Benefits of good requirements

• Fewer requirements defects

• Reduced development reworks

• Fewer unnecessary features

• Lower enhancement costs

• Faster development

• Fewer miscommunications

• Reduced scope creep

‹#›



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

‹#›



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 thedesign element

‹#›



Requirements from theCustomer’s Perspective

‹#›



Requirements from customers

perspective

• Who are customers?

– Individuals or organization who have benefits from a

product

• The one who request, specify, select , use, receive outputsfrom a software product

• They provide the business requirements

• Effectively collaborate with developers to derive successful

products

• Ones who sign off indicating approval of requirements

‹#›



Good Practices for RE

There are approximately 50 practices grouped into seven

categories :-

1. Knowledge

2. Requirements Management3. Project Management

4. Elicitation

5. Analysis

6. Specification

7. Validation

‹#›




-Knowledge

• Train requirements analyst

• Educate user reps and manager

about requirements

• Train developers in application

domain

• Create a glossary

‹#›




• 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


-Req. Management

‹#›




• Select the appropriate life cycle

• Base plans on requirements

• Renegotiate commitments

• Manage requirements risk

• Track requirements efforts

• Review past lessons learned


-Project Management

‹#›




• 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


-Elicitation

‹#›




• Adopt SRS templates

• Identify sources of requirements

• Uniquely label each requirement• Record business rules

• Specify quality attributes


-Specification

‹#›





-Validation

• Inspect requirements document

• Test the requirements

• Define acceptance criteria

‹#›



References

• Software Requirements; Karl E. Wiegers;

2nd Edition; 2003

week 5 - lecture 1 - fundamental of re

Documents