Business Analysis Session 6.

Landscape of RequirementsRAM N SANGWAN

WWW.RNSANGWAN.COM

YOUTUBE CHANNEL : HTTP://YOUTUBE.COM/USER/THESKILLPEDIA

TO LEARN OR TEACH JOIN WWW.THESKILLPEDIA.COM

1

Agenda

• Requirements - Features And Constraints

• Types Of Requirements

• Business, User and System Requirements

• Functional & Non-functional Requirements

• Requirements Source, Audience And Approval

2

Landscape of Requirements

• Perception changing from only emphasizing big three:

• Analysis, design, and construction

• Increasing Realization of criticality of

• Business Modeling and

• Requirements - their verification and traceability.

• More projects fail due to poor requirements specification and poorrequirements management than for any other reasons.

• that is, Changing Requirements and their management andscope creep – usually ‘not formal’ but ever-present!

3

Requirements: Difficult to Capture

• Sometimes done by BA (Business Analysts); sometimes done by

System Analysts - But not always!

• Sometimes (especially BAs)they have difficulty in mapping

abstract “needs” to “features” understandable by

developers…

• Sometimes done by developers with much input from BAs (know

the environment) and SAs and others.

• Typically developers have limited knowledge of application

domain.

• Developers often have difficulty communicating with

Business Analysts and others.

4/37

Landscape of Requirements

• Often developers don’t like to spend time here (we should, but wedon’t)

• “Takes too long”

• Developers like to plod on (often operating under falseassumptions).

• In fairness:

• Requirements can take form of huge requirements lists

• Horribly boring

• Difficult to discern critical needs from desires.

• Requirements may sometimes be dictated by a single person(depending on size of application, this may not be good! – Youwill get ‘that’ person’s views and biases.

5/37

Goals of Requirements Discipline

• To establish and maintain agreement with the customers and

other stakeholders on what the system should do and why.

• To provide system-developers with a better understanding of

the system requirements

• To define boundaries (delimit) of the system

• To provide a basis for planning the technical contents of

iterations

• To provide a basis for estimating cost and time to develop the

system

6/37

What are Requirements - IEEE

1. a condition or capability needed by a user to solve a problem

or achieve an objective

2. a condition or capability that must be met or possessed by a

system or system component to satisfy a contract, standard,

specification, or other formally imposed document

3. a documented representation of a condition or capability as

in (1) or (2)

Slide

: 7

What are Requirements?

• Requirements are capabilities and conditions to which the system

(and more broadly, the project) must conform.

• The purpose of Requirements is:

• To provide system developers with a better understanding of the

system requirements.

• To define the boundaries of (delimit) the system.

• To provide a basis for planning the technical contents of

iterations.

• To provide a basis for estimating cost and time to develop the

system.

• To define a user-interface for the system, focusing on the needs

and goals of the users.

8

Requirements Management

• Requirements management is a systematic approach to

• eliciting, organizing, and documenting the requirements of the

system

• establishing and maintaining agreement between the customer

and the project team on the changing requirements of the

system.

• Keys to effective requirements management include

• maintaining a clear statement of the requirements, along with

applicable attributes for each requirement type

• traceability to other requirements and other project artifacts.

9

Types of Requirements – FURPS+

• Functional

• features, capabilities, security.

• Usability

• human factors, help, documentation.

• Reliability

• frequency of failure, recoverability, predictability.

• Performance

• response times, throughput, accuracy, availability, resource usage.

• Supportability

• adaptability, maintainability, internationalization, configurability.

10

Types of Requirements – FURPS+

The "+" in FURPS+ indicates ancillary and sub-factors, such as:

• Implementation

• resource limitations, languages and tools, hardware, ...

• Interface

• constraints imposed by interfacing with external systems.

• Operations

• system management in its operational setting.

• Packaging

• Legal

• licensing and so forth.

11

Types of Requirements-another approach

Requirements are categorized as functional (behavioral) or non-

functional (everything else);

Functional Requirements

• Functional requirements are explored and recorded in

• the Use-Case Model

• the system features list of the Vision artifact.

Non-functional Requirements

• Other requirements can be recorded in the use cases they

relate to, or in the Supplementary Specifications artifact.

12

Type of Requirements - IIBA

IIBA have 6 types of requirement:

1. Business Requirements.

2. User Requirements

3. Functional Requirements

4. Quality of Service Requirements

5. Assumptions and constraints

6. Implementation requirements.

Slide

: 13

Requirement Documents

SRS (Software Requirements Specification)

• Functional requirements

• Use case Model

• Non-functional requirements

• Supplementary Specification

• Glossary

• records and clarifies terms used in the requirements.

• also encompasses the concept of the data dictionary, which recordsrequirements related to data, such as validation rules, acceptable values,and so forth

• User-Interface Prototype

Prototypes are a mechanism to clarify what is wanted or possible.

14

Requirements Levels

• Business & functional requirements are highlevel requirements …e.g. “be able to takeorders”

• Process and data models are low levelrequirements - rules …e.g. “customers haveto register before placing orders”

• as seen in Data and Process modellingsessions

15

Functional Requirements Examples

• The solution will automatically validate customers against the

ABC Contact Management System

• The solution will enable users to record customers sales

• The solution will enable Customer Order Fulfilment letters to be

automatically sent to the warehouse.

Question: What does “solution” mean in this context?

16

Examples of poor functional requirements

1. Be able to use diary functionality

2. Be able to flag premium customers

3. Be able to track and report on sales

4. Increase accuracy of sales information

5. Allow authorised users of team-leader and above to cancelsales orders

6. Prompt the owner of the sales order to notify the customer ofcancelled sales orders.

17

Source of Requirements

• Declared by Stakeholders• Interviews

• Workshops

• ‘Casual’ communications

• Constraining standards and procedures• Documents

• Interviews

• workshops

• Proposed by Business Analysts!• All the time

• Any way that is needed.

18

19/37Requirements Acceptance-Need

• Define features of system that meets needs of the stakeholders.

• While performing this step, it can be helpful to continually relatethe features of your proposed solution back to user needs.

• This may be accommodated using a mechanism (simple table)called a traceability matrix.

20

x x

x x

x x

Need #1

Feature #1

…

Need #n

Need #2

Feature #2 Feature #m…

Traceability Matrix – Leffingwell article

The Stakeholder needs are in the first column and the application features that we have defined to meet those needs constitute the columns.Features are normally found in the Product Vision document for the Application.

Traceability Matrix (more)

• We put Xs in the cells under the features that we havedefined to satisfy the stakeholder needs.

• Please note that this is a 1:n mapping, as there are far morefeatures than explicitly stated Needs.

• Further, the Needs are at high levels of abstraction.

• Study matrix.

• No X under a feature? Perhaps Need is not mapped intofeature(s)! Flag!!

• Features not traced back to a Need? Perhaps we haveFeatures that are not traceable back to Needs!

21/37

Continue the Traceability Mapping

• From the Product Vision Document for the Application, which

contains the desired Features derived from Stakeholder Needs,

we need tomap the Features to Use Cases.

• Consider the next two slides:

22/29

23/29

We continue with this figure – to the figure on the next slide…

24/29

from Leffingwell’s article. This figure says a great deal!!!

ProductFeatures,and more

This is what we are after….

ThankyouWWW.RNSANGWAN.COM

25