Requirements Management, Requirements analysis

<< Product-related Problems, Technology-related problems

Requirements Elicitation for Software >>

Software Project Management (CS615)

LECTURE # 13

2. Software Development Fundamentals

Technical Fundamentals

2.11

Requirements Management

⇒ Preview

Software requirements engineering is a process of discovery, refinement,

modeling and specification. The system requirements and role allocated to

software-initially established by the system engineer-are refined in detail.

Models of the required data information and control flow and operational

behavior are created. Alternative solutions are analyzed and a complete

analysis model is created.

Requirements engineering is the systematic use of proven principles,

techniques, languages, and tools for the cost effective analysis,

documentation, and on-going evolution of user needs and the specification

of the external behavior of a system to satisfy those user needs. Notice that

like all engineering disciplines, requirements engineering is not conducted

in a sporadic random or otherwise haphazard fashion, but instead is the

systematic use of proven approaches.

Both the software engineer and customer take an active role in software

requirements engineering-a set of activities that is often referred to as

analysis. The customer attempts to reformulate a sometimes nebulous

system-level description of data, function and behavior into concrete

detail. The developer acts as interrogator, consultant, problem solver and

negotiator.

The overall role of Software in a larger system is identified during system

engineering. However, it's necessary to take a harder look at software's

role-to understand the specific requirements that must be achieved to build

high-quality software. That's the job of software requirements analysis. To

perform the job properly, you should follow a set of underlying concepts

and principles. Generally, a software engineer performs requirements

analysis However, for complex business applications a 'system analyst'

trained in the business aspects of the application domain may perform the

task. If you don't analyze, it's highly likely that you'll build a very elegant

software solution that solves the wrong problem. The result is wasted time

and money, personal frustration and unhappy customers.

Software Project Management (CS615)

Data, functional, and behavioral requirements are identified by eliciting

information from the customer. Requirements are refined and analyzed to

assess their clarity, completeness, and consistency.

⇒ Requirements analysis

Requirements analysis is a software engineering task that bridges the gap

between system level requirements engineering and software design

(Figure 1). Requirements engineering activities result in the specification

of software's operational characteristics (function, data; and behavior),

indicate software's interface with other system elements, and establish

constraints that software must meet. Requirements analysis allows the

software engineer (sometimes called analyst in this. role) to refine the

software allocation and build models of the data, functional, and

behavioral domains that will be treated by software. Requirements

analysis provides the software designer with a representation of

information, function, and behavior that can be translated to data,

architectural, interface, and component-level designs. Finally, the

requirements specification provides the developer and the customer with

the means to assess quality once software is built.

Figure 1: a bridge between system engineering and software design

System

Engineerin

Software

Requirement

Software

Analysis

Design

Software requirements analysis may be divided into five areas of effort:

(1) Problem recognition,

(2) Evaluation and synthesis,

(3) Modeling

(4) Specification, and

(5) Review

Software Project Management (CS615)

Initially, the analyst studies the System Specification (if one exists) and

the Software Project Plan. It is important to understand software in a

system context and to review the software scope that was used to generate

planning estimates. Next, communication for analysis must be established

so that problem recognition is ensured. The goal is recognition of the basic

problem elements as perceived by the customer/users.

Problem evaluation

Problem evaluation and solution synthesis is the next major area of

effort for analysis. The analyst must define all externally observable

data objects, evaluate the flow and content of information, define and

elaborate all software functions, understand software behavior in the

context of events that affect the system, establish system interface

characteristics, and uncover additional design constraints. Each of

these tasks serves to describe the problem so that an overall approach

or solution may be synthesized. For example, an inventory control

system is required for a major supplier of auto parts. The analyst finds

that problems with the current manual system include:

(1) Inability to obtain the status of a component rapidly

(2) Two or three-day turnaround to update a card file

(3) Multiple reorders to the same vendor because there is no way to

associate vendors with components, and so forth.

Once problems have been identified, the analyst determines what

information is to be produced by the new system and what data will be

provided to the system. For instance, is the customer desires a daily

report that indicates what parts have been taken from inventory and

how many similar parts remain. The customer indicates that inventory

clerks will log the identification number of each part as it leaves the

inventory area.

Solution synthesis

Upon evaluating current problems and desired information (input and

output), the analyst begins to synthesize one or more solutions. To

begin, the data objects processing functions and behavior of the system

are defined in detail. Once this information has been established, basic

architectures for implementation are considered.

A client/server approach would seem to be appropriate, but does the

software to support this architecture fall within the scope outlined in

the Software Plan? A database management system would seem to be

required, but is user/customer's need for associativity justified? The

process of evaluation and synthesis continues until both analyst and

Software Project Management (CS615)

customer feel confident that software can be adequately specified for

subsequent development steps.

Throughout evaluation and solution synthesis, the analyst's primary

focus is on "what, not "how." What data does the system produce and

consume what functions the system must perform. What behaviors do

the system exhibit, what interfaces, are defined and what constraints

apply?

During the evaluation and solution synthesis activity, the analyst

creates models of the system in an effort to better understand data and

control flow, functional processing, operational behavior, and

information content. The model serves as a foundation for software

design and as the basis for the creation of specifications for the

Software. The customer may be unsure of precisely what is required.

The developer may be unsure that a specific approach will properly

accomplish function and performance. For these, and many other

reasons, an alternative approach to requirements analysis, called

Prototyping, may be conducted.

Table of Contents: