04 - analysis concepts and requirements workflow

8/2/2019 04 - Analysis Concepts and Requirements Workflow

1/37

Object-Oriented & Classical Software Engineering, 7th Ed.

Stephen Schach, 2007

McGraw-Hill International Edition

Requirements and

Analysis Workflows

What must the new product be able to do?


2/37

Outline

Requirements Workflow

Analysis Workflow

Requirements

Requirements Engineering Activities

Modeling the Requirements (separate slides)

Validation the Requirements (separate slides)


3/37

Requirements Workflow

Objective:

To determine the clients needs and constraints

Tasks:

Understand the application domain

Build a business model


4/37

Definition of Terms

Concept Exploration

Preliminary investigation of the clients needs

Application Domain

The specific environment in which the target product is

to operate or to be used, e.g., banking, military

Business Model

A document (containing UML diagrams) to describe the

clients business processes


5/37

Domain Analysis

Domain

The general field of business or technology in which the

customers expect to be using the software

Domain Analysis involves learning background

knowledge to enable the software engineer to:

Communicate with users

Be able to understand the problem

Be able to make intelligent decisions

Lethbridge and Laganiere, 2005


6/37

Domain Analysis

Sources of information

Domain experts or people who work in a domain and

who have a deep knowledge of it

Books about the domain Existing software on the domain and its documentation


Describe sources of information you can think of that can be

consulted in order to perform domain analysis in

Outline a short description of the information that you wouldneed to gather in order to perform analysis for


7/37

Analysis Workflow

Objective:

To analyze and refinethe requirements to achieve

the detailed understanding of the requirements

essential for Developing a software product correctly

Maintaining the software product easily

To specify product requirements using more

precise (or technical) language


8/37

Problem Definition and Scope

What is a Problem?

A difficulty the users or customers are facing

An opportunity that will result in some benefit such as

improved productivity or sales

What is a Solution?

Entails software development, or purchasing a software



9/37

Requirement

A feature of the software or a description of

something the software is capable of doing inorder to fulfill the systems purpose(Old INTROSESlides)

A statement about what the proposed system

will do that all stakeholders agree must be made

true in order for the customers problem to be

adequately solved(Lethbridge and Laganiere, 2005)


10/37

Types of Requirements

Functional Requirement

Describes an interaction between the software andits environment (Old INTROSE Slides)

Describes what the system should do or theservices provided for the users or other systems



11/37


Categories ofFunctional Requirement What inputs (data and commands) should the system accept

and under what conditions?

What outputs (screen, printer, I/O devices, servers) should

the system produce and under what conditions?

What data should the system store that other systems might

use?

What computations should the system perform?

The timing and synchronization of the above, if applicable



12/37


Non-functional Requirement

Describes restriction on the software that limits

the choices for constructing a solution to the

problem (Old INTROSE Slides) Constraints that must be adhered to during

development

Limits the resources that can be used

Sets bounds on aspects of the softwares quality



13/37

Non-Functional Requirements

Constraints on the design to meet the specified levels of

quality

Response time

Throughput e.g., transactions or computations per minute

Resource usage

Reliability

Availability

Recovery from failure

Allowances for maintainability and enhancement Allowances for reusability



14/37


Constraints on the environment and the technology of the

system

Platform

Technology to be used

Constraint on the project plan and development methods

Development process (methodology) to be used, e.g.,

specific testing approaches

Cost and delivery date



15/37

Example

Functional Requirements

The software should allow different types of files to be

accessed.

The software should print student grades.

Non-functional Requirements

Reliability: The software should inform the user if a file

type is not supported (instead of terminating abruptly or

hanging).

Response Time: The software should print student grades

in 30 seconds.

Old INTROSE Slides


16/37

Levels of Functional Requirements

Business Requirements

Describe why the software is being built

Identify the benefits both customers and business

organization will reap from the software Help the company operate more efficiently (for

information systems) or compete successfully in

the marketplace (for commercial products)

Wiegers, 2003


17/37


User Requirements

Describe the tasks or business processes a user will

be able to perform with the software

Modeled using use case diagrams

Functional Requirements

Describe the specific system behaviors that must

be implemented into the software to enable theusers to accomplish their task

Wiegers, 2003


18/37


SystemRequirements

Describe the top-level requirements for a product

that contains multiple subsystemsthat is, a

system A system can be all software or it can include both

software and hardware subsystems

People are a part of a system, too, so certain

system functions might be allocated to human

beings

Wiegers, 2003


19/37


20/37


Quality Attributes

Augment the description of the product's

functionality by describing the product's

characteristics in various dimensions that areimportant either to users or to developers

These characteristics include usability, portability,

integrity, efficiency, and robustness

Wiegers, 2003


21/37


Constraints

Impose restrictions on the choices available to the

developer for design and construction of the

product

External Interfaces between the system and the

outside world (user, another software, and/or

hardware devices)

Wiegers, 2003


22/37

Software Feature

A set of logically related functional requirements

Provides a capability to the user

Enables the satisfaction of a business objective

Wiegers, 2003


23/37

Example: Word Processor

Business requirement:

The product will allow users to correct spelling errors

in a document efficiently.

What are its features?

What are its user requirements?

What are its functional requirements?

What quality attributes should it provide?

Wiegers, 2003


24/37

Product feature:

Spell checker

User requirements (tasks or use cases to support the productfeature):

Find spelling errors

Add word to global dictionary

Quality attribute

Usability

Efficiency


Wiegers, 2003


25/37

Functional requirements or operations:

Finding a misspelled word

Highlighting a misspelled word

Displaying a dialog box with suggested replacements

Globally replacing misspelled words with corrected

words


Wiegers, 2003


26/37

Requirements Development


27/37

Requirements Elicitation

Process of discovering the clients requirements

Communication-intensive process

The most difficult part is helping users figure out

what they want Methodology:

Interview

Survey or questionnaire

Observation Document review (forms, reports)


28/37

Document Review

Obtain copies of all input forms, both filled in and blank, and all

output reports, if possible.

How often it is produced?

How many copies are generated?

Who receives the copies?

Study the existing system documentation.

Deliverables that were performed

Policy manuals and specifications of procedures, programs, data, and interfaces

Written manuals and help files embedded in the software Negative documentation such as system errors, employee complaints

The documentations age is a clue to its reliability.

Old INTROSE Slides


29/37

Observation

Observe the current procedures.

Real operation vs. theoretical procedures written in the

documents

Obtain permission from both the person to be observed and thatpersons supervisor; and explain the purpose

Observe normal procedures and exceptional cases

Participatory Observation

Stay out of the way, making certain we do not interrupt ordisturb the activities in progress.

Old INTROSE Slides


30/37

Requirements Analysis

Problem identification and analysis

Process of refining and extending the initial set

of requirements elicited from the client

Organizational/process modeling

Systems analysts (or Business analysts) focus on

what, not how

Old INTROSE Slides


31/37


The Myth of Stable Requirements

First law of system engineering [Bersoff]:

No matter where you are in the system life cycle,

the system will change, and the desire to changewill persist throughout the life cycle.

Users dont know what they want.

Old INTROSE Slides


32/37


The Myth of Complete and Consistent Requirements

Large systems are viewed as wicked problems:

Diverse user community with different priorities Users are not the people who pay for the system

Old INTROSE Slides


33/37


34/37

Requirements Specification

A document that describes the system to be

developed in a format that can be reviewed,

evaluated, and approved in a systematic way

(Cleland-Huang, 2005) Constitutes a contract

Should not include imprecise terms like suitable,

convenient, ample, enough, etc.

Essential for both testing and maintenance In the Unified Process, a set of UML artifacts

constitute the specification document


35/37


36/37

Requirements Specification

Common problems:

Ambiguous two or more different interpretations

or meanings

Incomplete missing some relevant fact orrequirement

Contradictions


37/37

References

Jane Cleland-Huang, 2005. Software Requirements.IEEE

Software Engineering, 3rd ed., Volume 1.

T. Lethbridge & R. Laganiere, 2005. Object-oriented

Software Engineering: Practical Software Development

using UML and Java. London: McGraw-Hill

I. Sommerville, 2004. Software Engineering, 7th ed.

Pearson Education

Karl Wiegers, 2003. Software Requirements, 2nd ed.

Washington: Microsoft Press.

04 - analysis concepts and requirements workflow

Documents