MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009

8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009

1/71


2/71

Course outline

Module 1 - Requirements Essentials

What is a requirement?

Where do requirements come from?

How are requirements recorded?

Process of collecting requirements

Quiz

Module 2 - Requirements Engineering process

Requirements Elicitation Requirements Analysis

Requirements Specification

Requirements Validation

Requirements Management & Traceability

Quiz


3/71

MODULE 1

Requirements essentials

Objectives What is a requirement?


How are requirements recorded?

Process of collecting requirements


4/71

What is a requirement?

In engineering, a requirement is a singular documented need of what a particularproduct or service should be or do.


5/71


6/71


Requirements

Usermodifications

User groupmeetings

Workshops

Prototypes

StudiesInnovation work

Questionnaires

Consultants &Trainers

Observation /Fieldwork


7/71

Why are requirements are important?

Designing and building an elegant computer program that solves the wrong problemserves no ones needs.


8/71

Why are requirements are important?

Cost of finding bug is cheaper when compared with the same bug is found in thelater stage


9/71

How are requirements are recorded?

Use cases

Documents

Data dictionary

State diagrams

Scenarios

System diagrams


10/71


11/71

Module 2

Requirements engineering tasks

Objectives RequirementsElicitation

RequirementsAnalysis

RequirementsSpecification

RequirementsValidation RequirementsManagement & Traceability

Quiz


12/71

Requirements Engineering Process


13/71

What Is Requirements Elicitation?

View

Art of listening to Stakeholders

Art of sending appropriate stimuli to stakeholders so that the responses are worth listeningto

The art of establishing an environment in which stakeholders are willing and able todescribe their problems and needs

Observations

Elicitation is the input to all system development

Elicitation technique varies greatly across projects

No one technique is universal

Completeness can never be assured

Lots of human nature and communication problems


14/71


15/71

Requirements - Capture

Map out business

activities Build process flows for

key activities

Review business map

with stakeholders

map needs more work

Review scenarios

with stakeholders

scenarios agreed

Review process flows

with stakeholders

workflow needs more work

Build scenarios for key

activities where IT required

map agreed

scenarios need more work

Identify Use

Cases

workflow agreed

Review Use Cases

with stakeholders

Use cases need more work


16/71

Requirements - Elicitation techniques

To address the problems, the following techniques were discussed:

Interviewing and questionnaires

Requirements workshop Brainstorming and idea reduction

Storyboards

Use cases

Role playing

Prototyping

How do we choose the right technique for elicitation?


17/71

Elicitation Techniques : Interviewing

Simple direct technique : Personal substitute for questionnaire.

Pre Requisites for Interviewing:

Establish Customer or User Profile

Understanding the User Environment

Step 1:

Context-free questions can help achieve bias-free interviews

Goal is to prevent prejudicing the users response to the questions

Step 2:

Then, it may be appropriate to search for undiscovered requirements by exploring solutions. Step 3:

Convergence on some common needs will initiate a requirements repository for use duringthe project.

Step 4: Showtime

Assessing the Problem

Recap the Understanding

Analysts Inputs on Customers Problems

Assessing Your Solution (if applicable)


18/71

Interview Strategies :Structure of Interviews

Open-ended questions

Start with closed questions

Expands to

start with a general questions

end with a specific question

specific

general

specific

Diamond-ShapedDiamond-Shaped

FunnelFunnel

PyramidPyramid


19/71

Elicitation Techniques : Requirements Workshops

The requirements workshop is perhaps the most powerful technique for elicitingrequirements.

It gathers all key stakeholders together for a short but intensely focused period. The use of an outside facilitator experienced in requirements management can ensure

the success of the workshop.

Brainstorming is the most important part of the workshop.


20/71

Role of the Facilitator

Establish professional and objective tone to the meeting.

Start and stop the meeting on time.

Establish and enforce the rules for the meeting.

Introduce the goals and agenda for the meeting.

Manage the meeting and keep the team on track.

Facilitate a process of decision and consensus making, but avoid participating in thecontent.

Make certain that all stakeholders participate and have their input heard.

Control disruptive or unproductive behavior.


21/71

Workshop Agenda

Set an agenda before the workshop and publish it along with the other pre-workshopdocumentation.

Balance is the key, try to stay on the agenda, but do not strictly obey it, especially ifgood discussion is going on.

Order lunch in, and have a light working lunch.


22/71

Requirements Elicitation Guidelines

Assess System Feasibility

Be sensitive to organizational and political considerations

Identify and consult system stakeholders

Record requirements sources

Use Business concerns to drive requirements elicitation

Look for domain constraints


23/71

Identify and Consult System Stakeholders

If lacking consideration of everyone who is likely to be affected by the introduction ofthe system, there is a great likelihood of missing some critical requirements.

Identifying stakeholders and discussing the system with them makes people feel likethey are part of the requirements elicitation process. In fact, it makes them a part ofit.


24/71

Use Business Concerns to Drive Requirements Elicitation

If a system is to be useful, it must contribute to the key concerns of the business. Ifthe concerns are identified and used as drivers of the requirements elicitation process,

there will be higher confidence that the system will meet real organization needs.

Making the business concerns explicit helps to focus and clarify these goals.


25/71

Collect Requirements from Multiple Viewpoints

If requirements are collected from a single viewpoint, they are unlikely to meet otherstakeholders requirements.

Collecting requirements from multiple viewpoints is a useful way to prioritizerequirements.

Identified viewpoints can be used to help

organize requirements elicitation and

organize the requirements specification, too.


26/71

Elicitation Techniques : Brainstorming

Brainstorming

involves both idea generation and idea reduction

Is the most creative, innovative ideas often result from combining, seemingly unrelated ideas Rules:

Do not allow criticism or debate

Let your imagination soar

Generate as many ideas as possible

Mutate and combine ideas

Idea Reduction

Pruning ideas that are not worthy of further discussion

Grouping of similar ideas into one super topic

Prioritize the remaining ideas


27/71

Elicitation Techniques : Storyboarding

The purpose of storyboarding is to elicit early Yes, But reactions.

Storyboards can be positive, active, or inactive.

Storyboards identify the players, explain what happens to them, and describes how ithappens.

Make the storyboard sketchy, easy to modify, and unshipable.

Storyboard early and often on every project with new or innovative content.


28/71


29/71

Elicitation Techniques : Prototyping

Prototyping is especially effective in addressing the

Yes, But Syndrome

the Undiscovered Ruins Syndromes A software requirements prototype is

a partial implementation of a software system

built to help developers, users, and customers

better understand system requirements

Prototype the fuzzy requirements: those that, although known or implied, are

poorly defined and poorly understood


30/71

Interface to humans/userinterfaceUse prototyping, scenarios,modeling

Essential operating activitiesUse apprenticing, interviews,scenarios

Right selection of elicitation technique

Rigorous modeling of everything is likely not feasible

Prototyping everything is likely not feasible

Match requirements/analysis techniques to needs and situations

BusinessLogic

Interface

Information

Policy architecture, stored dataUse interviews, existing systemsanalysis


31/71

Requirements Analysis

Goals of requirements analysis and specification phase:

fully understand the user requirements

remove inconsistencies, anomalies, etc. from requirements document requirements properly in an SRS document

Analyst gathers requirements through:

observation of existing systems,

studying existing procedures,

discussion with the customer and end-users,

analysis of what needs to be done, etc.

After gathering all the requirements:

Analyse it:

Clearly understand the user requirements,

Incompleteness and inconsistencies


32/71

Requirements Modeling

Requirements modeling is more than an intuitive way of figuring out the functionalrequirements of a system. It is the application of a process of proven techniques to

produce useful and verifiable models.

Use Case modeling, Data modeling and UML (Unified Modeling Language) areexamples of Requirements Modeling methods.


33/71


34/71

Use Case

A meaningful piece of system functionality

Jakobson treats business processes as use cases of the business (a business is a

system too) More than a simple transaction (e.g. enter customer address)


35/71

Example

An ActorA Use Case

Change Invoice Add item to sales ledger

Chase Payment Issue Warning Letter


36/71

Example

Val idate

C u s t o m e r

Take O r de r

Detai ls

R e q u e s t

De l ivery Date

R ead O r de r D e t a il s ToC u s t o m e r

change r eques ted

de l i very date not acceptab le

C h e c k N u m b e r

W i th C us t om er

N o va l id num ber

cus t om er ag r ees

Trans fer Ca l l[ query fo r sa les team ]

C heck P r oduc t

C o d e

incor rec t p roduc t co de

R eques t C hange

of Order

c red i t lim i t exceede d

increase

cred i t

l imi t

r eques t


37/71

Prioritizing Requirements : Why it is important?

Projects cannot avoid the following fundamental facts of life:

Differences in importance

Limited project resources Long schedule

Small RE budget


38/71

What is priority ?

According to the Merriam-Webster Online Dictionary, the term priority means:

The state of being prior (i.e., given precedence in terms of date or time)

Given or meriting attention before competing alternatives Given preference

For them, prioritizing requirements means categorizing raw potential requirementsfrom the standpoint of importance into:

Essential requirements

Useful capabilities

Desirable capabilities

Based on the preceding, prioritizing real requirements could mean:

Prioritization by implementation order

Prioritization by importance


39/71

Challenges and Risks

Mandatory nature of requirements

Large number of requirements

Limited resources Quality requirements

Goals vs. requirements

Changing priorities

Incompatible priorities

Stakeholder and developer collaboration

Incompatible requirements

Lack of trust

Non-requirements

Subjective prioritization

Consequences of poor prioritization


40/71

Software Requirements Specification

Main aim of requirements specification:

systematically organize the requirements arrived during requirements analysis

document requirements properly The SRS document is useful in various contexts:

statement of user needs

contract document

reference document

definition for implementation

C

oncerned with the structure, quality and verifiability of the requirements document. Results in one document with 2 parts or 2 separate documents:

System requirements definition document

Software requirements specifications (SRS)


41/71

System Requirements Specification

Also known as User Requirements document

Also known as Concept of operations

It must list the system requirements along with background information about theoverall objectives for the system, its target environment & a statement of theconstraints, assumptions & non-functional requirements

Establishes the basis for agreement between the customers and the developers

Forces a rigorous assessment of requirements before design can begin

Provides a realistic basis for estimating product costs, risks, and schedules Provides an informed basis for transferring a software product to new users

Provides a basis for software standards


42/71


43/71

System Requirements

To be used efficiently, all computer software

Needs certain hardware components or other software resources to be present

Known as (computer) system requirements and Often used as a guideline as opposed to an absolute rule.

Most software defines two sets of system requirements:

Minimum

The 'Minimum system requirements' must be satisfied for the software to be usable at all

Computers with lower specifications than the minimum requirements may sometimes also run thesoftware

It is suggested, however, that the user will not have a representative experience of the software thisway. Generally this set is regarded more of a rule than a guideline

A system meetingthis requirement will provide basic performance of a software application

Recommended

Recommended system requirements are often suggested by Software Vendors for optimalperformance of a software

Although not a necessity, this set of requirements is often sought after by power users who expect togain a better experienceof software usability

Recommended System Requirements do not promise best possible performance of a software and aretreated as more of a guideline than a rule

Almost always a better system is available, or will be in future, to provide better performance. Also,exceeding by far these requirements does not guarantee to the user that everything will run withabsolute smoothness and look its best

More often than not, games are a bit disappointing in this respect, presenting issues that may or maynot be corrected with future modifications.


44/71

Hardware Requirements

The following are the various aspects of hardware requirements

Architecture

Processing power Memory

Secondary storage

Display adapter

Peripherals

Software Requirements deal with defining software resource requirements and pre-requisites that need to be installed on a computer to provide optimal functioning of

an application. Platform

APIs and Drivers

Web browser

Other requirements


45/71

Purpose of SRS

Contract Between Acquirer & Provider OfCapability

Defines what is to be provided

Establishes when and how things are to be provided Provides the Basis for:

Assessing proposed engineering changes

Resolution of acquirer/provider disputes

Development of test requirements

Preliminary user's manual

Maintenance & support planning


46/71

Scope of SRS


47/71

What makes a good SRS?

Points to be considered for producing a good SRS

Nature of the SRS

Environment of the SRS Characteristics of good SRS

Joint preparation of SRS

SRS evolution

Prototyping

Embedding design in SRS

Embedding Project requirements in the SRS


48/71

Benefits of SRS

SRS is useful as it helps us

to discover how to partition the system

to identify which requirements should be allocated to which components maintain is good communication between system users and system developers. It is the

requirements engineer who is the conduit for this communication

to acquire / possess technical skills

to have an ability to acquire an understanding of the application domain

to develop the inter-personal skills to help build consensus between heterogeneous groupsof stakeholders


49/71

SRS should refer to

Customers : deliverables which provide basis for development

Managers : scheduling basis and is a basis for measurement of progress

Designers : specifications for design

Developers : provide acceptable implementations

Maintainers : enables modification and enhancement

Users : for providing right look and feel, performance and behavior

QA : basis for process compliance

Testers : basis for validation, test planning and verification


50/71

Characteristics of SRS

Independent

Annotated

Concise Easy to Validate

Appropriate Abstraction Level

Testable

Correct

Unambiguous

Complete Verifiable

Consistent

Understandable

Modifiable

Traceable

f


51/71

Structure of a SRS

Introduction Purpose

DocumentConventions

Intended Audience

Reading Suggestions

Product / Project Scope

References

Overall Description Product Perspective

Product Functions

User Classes and Characteristics

Operating Environment

Design & ImplementationConstraints

Assumptions & Dependencies

External Interface Requirements User Interfaces

Hardware Interfaces

Software Interfaces

Communication Interfaces


52/71

Some Statistics

It costs 68 to 110 times more

to correct an requirement defect found by the customer rather than

to fix an error identified in requirement development activity

Time taken to fix a defect

30 minutes at the requirement development

5 to 17 hours to correct at System Testing


53/71

Objectives

Ensure the following:

SRS correctly describes the intended system behavior and characteristics

Software requirements were correctly derived from system requirements or other origins Requirements are complete

Requirements are of high quality

All views of requirements are consistent

Requirements provide an adequate basis to proceed with design, construction and testing

R i t R i C l


54/71

Requirements Review Cycle

Plan the

Review

Cycle

Obtain

Review

Comments

Classify & Sort

Comments

Conduct

Review

Meeting

Update

Requirements

Document

Execute

Agreed

Actions

Pre-review Baseline

All reviewers

work fromsame version

Post-review Baseline

Approved

version


55/71

Techniques

ReviewsInformal Reviews

Buddy ChecksWalkthroughFormal Technical Review

InspectionsHighest leveragesoftware qualitytechnique

Conducted beforethe baseline ofrequirementsisdevelopedParticipants

AuthorModeratorReaderRecorder

Stages

PlanningOverview MeetingsPreparationInspection MeetingReworkFollow-up Meeting

Entry CriteriaExit Criteria

Requirement Inspection Checklists


56/71

Requirement Review Challenges

Large Requirement Documents

Do NOT wait till the requirements are baselined

Perform incremental reviews during the development of SRS Start at different locations of the document to ensure complete coverage

Large Inspection Teams

Makes it difficult to schedule meetings

Difficulty to reach agreement on requirements and related issues

Geographic separation of reviewers

Collaboration is difficult

Communication costs and coordination is a very big issue

f l d


57/71

Software Requirements Validation

Concerned with the process of examining the requirements document to ensure thatit defines the right system:

Reviews

Prototyping

Model Validation

AcceptanceTesting

i


58/71

Requirements Management

Requirements

An activity that spans the whole software lifecycle.

It is fundamentally about change management and the maintenance of the requirements in astate that accurately mirrors the software to be, or that has been, built.

sIt includes change management, requirements attributes and requirements tracing

R i T bili


59/71

Requirements Traceability

Traceability is

one of the essential activities of good requirements management.

is used to ensure that the right products are being built at each phase of the softwaredevelopment life cycle, to trace the progress of that development and to reduce the effortrequired to determine the impacts of requested changes.

R i t Ch M t


60/71

Requirements ChangeManagement

General Patterns

Requirements changes usually cause all subsequent phases ( design, implementation, testing) change.

Any changes in subsequent phases may force requirements to change.

Every change introduced may potentially alter the requirements quality: consistency andcompleteness .

Changes can come Externally

The problem changed.

The users changed their minds or their perceptions.

The external environment has changed. The project team has no control over these external factors.

R i t Ch M t


61/71

Requirements ChangeManagement

Changes can come Internally

Misunderstandings in the RE process

Refining the understanding of the problem and possible solutions in the design phase Implementation limitations discovered during implementation

Defects discovered during testing or test case generation

Defects discovered during system operational lifetime

Wh t d it i l ?


62/71

What does it involve?

Change Control

ProposingC

hanges Analyzing Impact

Communicating

Making Decisions

Incorporation

Measuring Requirements Stability

Version Control

Identifying requirements document versions

Identifying individual requirement revisions

Wh t d it i l ?


63/71

What does it involve?

Requirement Tracing

Defining links to other requirements

Defining links to other system elements

Requirements Status Tracking

Defining requirements statuses

Tracking requirements that have each status

Change Control Process


64/71


Benefits

Provides a formal mechanism to propose changes in requirements

Enables project leaders make informed decisions about the changes Lets you track the status of all proposed changes

Ensures that no suggested changes are lost or overlooked

Ensures funneling and filtering to ensure that most appropriate changes are incorporated

Change Control Policy

States expectations on how proposed changes to requirements will be handled



65/71

Change Control Process.

Roles involved

Change

Control Board

Chair

Evaluator

Modifier

Originator

Project Manager

Request Receiver

Verifier



66/71

Change Control Process.

Measurement ofChange activity

Requests received / open / closed Cumulative changes made, including added, deleted

Number of change requests originating from a source

Number of changes proposed and made in a given requirement baseline

Total effort involved in making the changes at various stages

Process for Managing Change


67/71

Process for Managing Change

A process for managing changes effectively must include the following steps:

Recognize thatC

hange is inevitable Baseline the requirements

Establish a single channel

Use a change control system

Manage change hierarchically

Change Request Diagram


68/71

Change Request Diagram

References


69/71

References

Websites :

http://www.westfallteam.com

http://www.processimpact.com http://www.vbhconsulting.com/

http://www.westfallteam.com/

White Papers :

Issues in Requirements Elicitation by Michael G Christel & Kyo C Kang

http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf

http://www.borland.com/resources/en/pdf/solutions/rdm_whitepaper.pdf

http://www.ee.unb.ca/kengleha/courses/CMPE3213/Requirements.htm

http://aaaprod.gsfc.nasa.gov/TEAS/lr-web/lindarose.html

Books:

Requirements Engineering: A Good Practice Guide: by Ian Sommerville, Pete Sawyer

Requirements Engineering by Elizabeth Hull (Author), Kenneth Jackson (Author), JeremyDick(Author)

References


70/71

References

http://www.ksc.com/education/oocourses/%60iterative.htm

Software Engineering Roger S.Pressman

Software Engineering - David Gustafson en.wikipedia.org/wiki/Software_requirement

Q?????


71/71

Q?????

MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009

Documents

Transcript of MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009