Requirements Analysis

Requirements Analysis

Commonly cited root causes of failure one third of the software projects (Standish Group, 1994)

• Lack of user input • Incomplete requirements and specifications • Changing requirements and specifications

Relative cost to repair a requirements error

100 Cost of repairing a requirements 10 error

1

0.1 Analysis

Design

Coding

Testing

Implementation

User Needs, Software Features, and Software Requirements • Software requirements reflect specific features of user needs. Arise when business or technical problems are faced Problem Domain

Solution Domain

Needs

A service that the system provides to fulfill stakeholders’ need

Features

•A software capability needed by the user to solve a problem to achieve an objective.

Software Requirements

•A software capability that must be met or possessed by the system or system component to satisfy a contract, standard, specification or other formally imposed documentation.

Classes of User Requirements (Sommerville, 1999)

• Enduring Requirements: Core and stable • Volatile Requirements: Change during development or operation of the s/w – Mutable requirements: change due to changes in the environment – Emerging requirements: appear as users begin using the s/w – Consequential requirements: appear when a computer system replaces a manual one. – Compatible requirements: appear when business processes change

Classes of User Requirements (Robertson, 2000)

• Conscious (users are aware of them) • Unconscious (users assume everyone knows them) • Undreamt of (user asks them when he realizes it is possible)

Sub-phases of Requirements Phase • Requirement gathering • Systems analysis Requirement gathering Effort Systems analysis

Time

Endemic Syndromes in requirement elicitation process • The “Yes, But” syndrome – stems from human nature and the users' inability to experience the software as they might a physical device

• The “Undiscovered Ruins” syndrome – the more you find, the more you know remain

• The “User and Developer” syndrome – reflects the profound differences between the two, making communication difficult

Difficulty in Understanding User Information Requirements • Limited rationality of human mind • The variety and complexity of information requirements • Complex pattern of interaction among user and analyst • Unwillingness of some users to provide requirements for political and behavioral reason

Limited Rationality of Human Mind • Humans are not very good information processors. • Limits on human short-term memory • Bias in selecting and using data – Anchoring and adjustment – Concreteness – Recency – Intuitive statistical analysis – Placing value on unused data

Strategies for Determining Information Requirements • Asking – Interviewing each user separately – Group meetings – Questionnaire Survey (Delphi Techniques)

• Deriving from an Existing Information System – Existing information system – System that is in operation in another, similar organization – System that is standardized and it exists in a package that can be adopted and customized – Systems described in textbooks, handbooks and alike

Strategies for Determining Information Requirements • Synthesis from the characteristics of utilized system – Input-process-output analysis – Decision analysis

• Discovering from Experimentation with an existing Information System – Prototyping

Selecting an Appropriate Strategy • • • •

Characteristics of the utilized system Complexity of the Information System Ability of the user to specify requirements Ability of the analysts to elicit and evaluate requirements

Prototyping Synthesis

derived Asking High

Low Level of overall uncertainty

Requirement Gathering Sub-phases • • • • • • •

Set the project scope Search for requirement Write requirements Verify and validate requirements Review the requirement specifications Prototype the requirement Reuse requirements

Work Context

Requirements for Prototype

Set the project scope

Prototype the requirement

Potential Requirement

Search for requirements

Formalized Requirement

Write the requirements

Verify and validate Reqmt

Reuse Requirements

Activities in Requirements Gathering Sub-phases

Requirements Specification

Reviewed Specification

Set the project scope

Set the Project Scope • Recognize the stakeholders of the project – The Client : Who pays for the development of the product – The Customer : Who is going to buy the product – The User : Who is going to operate the product – Management – The functional manager, the project sponsor, the project leaders. – Domain Analyst – Business consultant and analyst who has some specialized knowledge about the domain – Developers – System analysts, product designer, programmer, testers, database designers, technical writers.

– – – – – –

Marketing Personnel: (If the product is for sale) Legal Personnel: Lawyers Oppositions – People who do not want the product Professional bodies - who sets guidelines and norms Public – In case the product is for the general public Government Agencies – In case some information passes to the government – Special Interest Groups – Environmental groups, affected groups like workers, Senior citizens, religious and ethnic groups. – Technical Experts – Hardware and software experts

Set the Project Scope • Brainstorm the appropriate stakeholder • Determine the work context and the product scope – Product Purpose • Statement of purpose, business advantage, reasonableness, feasibility

– Requirement constraints • Solution Constraints : Specific h/w, s/w, design, interfacing with some existing product • Project constraints : Time and Cost

– Names, aliases, and definitions – The product scope • The activity that the user needs • Adjacent external systems and events they generate • Response of the system under study to these events

– Preliminary estimates of time cost and risks involved – Go / no-go decision

Search for Requirement • • • • • • • • • • • • •

Understand how the work responses are generated Apprenticing Observe abstract repeating pattern Interviewing the users Getting essence of the system Business event workshops Requirements workshops Brainstorming Study of documents Making Videos Using electronic media Storyboards Scenario Models

Prototyping the Requirements • Need not be a s/w – Drawings on a paper – Clip-charts – Use-cases on paper, white board or clipcharts

• With reference to adjacent external system events • With reference to major tasks the product is suppose to do

Write the requirements • Requirement template – Product constraints – Functional requirements – Non-functional requirements – Project issues

Functional Requirements • Functional requirements specify what the product must do to satisfy the basic reason for its existence. They are – – – – – – –

Specification of the products functionality The actions the product must take Derived from the basic purpose of the product Normally business oriented rather than technical Derived mostly from use case scenarios Not measurable or testable at this stage To be free from ambiguity

Non-functional requirements • The properties or the characteristics the software product must have to perform a task (functional requirements) – – – – – – – –

Look and feel requirement Usability requirement Performance requirements Operational requirements Maintainability requirements Security requirements Cultural and political requirements Legal requirements

Project Issues • • • • • •

Off-the-self solutions New problems Tasks Risks Costs User Documentation

Verify and Validate Requirements • Examining the requirements listed in requirement template to decide whether it should be included in the Requirement Specifications – Establish fit criteria (measurable scales) for each requirement – Test each requirement for completeness relevance and viability

Establish Fit Criteria • Fit criteria for – Functional Features Ex. The computed value shall agree with the specified scheme provided by the user

– Non-functional features Description: The product should not be offensive to Japanese Fit Criterion: The cartoons used should be certified by the Department of Japanese Studies

– Each use-case Description: Generate master production schedule Fit Criterion: The schedule will be made for a year and will be made for the refrigeration division and air conditioning division only.

– Each constraints Description: The product should be run on the windows operating system Fit Criterion: The product should be upward compatible from Windows 2000 onwards

Testing Requirements •

Completeness : Tests to find out missing requirements – Data Models: DFDs, ER diagrams, Class Diagrams – Object life history (or state) diagrams

•

Traceability : Tests for finding features to enhance traceability – – – – –

•

Unique Identifier for each requirement An indicator for the type of requirements References to all business events and use cases References to dependant requirements References to conflicting requirements

Consistent Requirements – Defining Terms – Using a term in a manner consistent with its specified meaning – Looking for inconsistencies

•

Relevance – To the purpose of the product

Testing Requirements • Viability – With specified constraints

• Solution boundedness – Should not be described in terms of a solution

• Gold Plating – Cost for providing a piece of information should not outweigh its value

• Creep – Searching for missed requirements – Review of the requirements process

• Conflicting – Requirements that are impossible or difficult to be implemented simultaneously

• Ambiguity – Making different interpretation of the same requirement

Reviewing the requirements specification • • • •

By the customer, the user, the analyst etc. Individually and jointly Doubts must be mitigated Resulting Document – User Requirements Specification (URS)

Reusing Requirements • Library of Generic Requirements

Traditional Tools for Requirements Gathering

Document flow charts • A document flow chart indicates the flow of documents from one department to the other. It brings light the following: – The number of copies of a document – The place (and/or the person) of origin of the document – The destination of the document (place and/or person) – The decisions and actions taken at various places (or by various persons) where the document is sent.

Why to use Document flow charts • Documenting the existing information system • Understanding the existing procedure of decision making • Convincing the client that the analyst has fully understood the system • Analyzing the good or bad points of the existing system – Identifying unnecessary movement of the documents – Identifying wasteful and time-consuming procedures – Suggesting new procedures

Symbols used in Document Flow Charts

Document

Flow of document

Document and its copies

Storage of Document

Related Documents

Annotation giving textual explanation

User Department Letter of Interest

Letter of Interest Sanction Letter

Deputy Director

DR F/A

Suppliers

Letter of Interest

Sanction for the purchased obtained

Letter of Interest Sanction Letter Funds Booking Done

Call for Quotation

Quotation

Comparative Statement

Sanction Letter

Mailed to suppliers

Quotation

Purchase Department

Tools for Representing Condition-Action Combination • • • • •

Logic Flow Charts Structured English Decision Table Decision trees …

Logic flow chart Start

No

Yes

Is it a textbook

Are funds available

Are funds available No Waitlist the book for next year

Yes

Yes

Buy the books

Buy the books

Finish

No Return the Reco to HOD

Structured English In the book is a textbook then if the funds are available then buy the book else waitlist the book for the next year endif else if the funds are available then buy the book else return the recommendation to the HOD endif endif

Decision tables • A compact way • Conditions defined in a binary way • Condition entries are yes/no type • The list of actions • Action entries are cross marked to indicate the appropriate action when a set of conditions are satisfied.

Conditions

Decision Rules

Text Books?

Y

Y

N

N

Funds Available?

Y

N

Y

N

Actions Buy Waitlist for next year Return to HOD

X

X X X

Removing Redundancies from the Decision tables • Identify two rules with same action. • If they differ in their condition entries in one row. They can be merged

Conditions

Decision Rules

Text Books?

-

Y

N

Funds Available?

Y

N

N

Actions Buy Waitlist for next year Return to HOD

X X X

Identifying Misspecification Using Decision Table • More than one cross mark for decision a rule (ambiguity) • No cross mark for a decision rule (missing action)

Conditions

Decision Rules

C1

Y Y N N

C2

Y N Y N

Actions A1

X

A2 A3 Ambiguity Missing Action

X X

X

Decision Table Hierarchy

Conditions

Decision Rules

Product is refrigerator?

Y

Actions Go to refrigerator Table Go to air conditioner Table

Conditions

Decision Rules

Order Quantity > 10

Y

Y

Delivery Time > 2 wks Y

N

Give 10 % discount Do not give discount

X X

Conditions

Decision Rules

N

Order Quantity > 5

Y

Y

N

-

Delivery Time > 4 wks

Y

N

-

Actions Give 20 % discount

N

Actions X

Give 10 % discount X

Give 5 % discount X

Do not give discount

X X X

Decision table vis-à-vis Logic Chart Start Y Math > 90%

N

Phy > 90%

Y Phy > 90%

N

Y

N

Y N Total > 80% Y

Admit on probation

Admit Stop

Do not Admit