MANAGING

LESSON 22: REQUIREMENT DETERMINATION

Objective
The objective of this lesson is to give you an insight into:
Definition of Requirement Determination. Components of Requirement Determination. Stages of Requirement Determination. Types of Requirement. Activities of Requirement Determination.

INFORMATION SYSTEM

how current methods working and whether adjustments are necessary or possible. These studies consider both manual and computer methods, as we shall see; they are not merely computer studies. Thus, Requirements Determination, includes the following:
Requirements determination involves requirements

acquisition, requirements analysis and re-quirements specification,

This is the least well-defined stage of the whole systems

Introduction
So far, we have studied that what are the various categories or the computer based systems used in the business, their characteristics, their behaviour, and their suitability according to the different nature of the business. We have also got some idea about system analysis and design and with that we have already seen that developing a proposed system passes through so many different phases. In those different phases, requirement analysis is one of the very important phases where our analyst tries to analyze the requirements of an on-going system by conducting various activities. Here, in this chapter we will be discussing the various aspects of system requirements, their analysis and determi-nation. This chapter guides you that what is the need for system requirement, what actually these system requirements are and how system analyst determined them? What are the various tools which system analyst can use to analyze and determine the system requirements? As we have already studied that system analysis is all about understanding situations, not solving problems. Effective analysis therefore emphasize investigation and questioning to learn how a sys-tem currently operates and to identify the requirements users have for a new or modified one. Only after analysts fully understand the system are they able to analyze it and assemble recommendations for systems design. A critical step in developing a Geographic Information Systems (GIS) is to assess the needs and requirements for a potential system. This is a common problem in systems design of all kinds (information systems are just one example, and GIS is probably less formalized than most other applica-tions). Before starting with requirement determination, first of all, I would like to know that what do you understand by a requirement? A requirement is a feature that must be included while developing a new system. It may include a way of capturing or processing data, producing information, controlling a business activity, or sup-porting management. The determination of requirements thus entails studying the existing system and collecting details about it to find out what these requirements are.

development process and varies greatly from organization to organization.

Also it is difficult as requirements can frequently change

Now what is Requirements Acquisition? It includes the following:

Analysis of existing system - outputs, inputs, procedures etc. Observation of existing behaviour and workflow -

participative or non-participative.
Analysis of desired systems documentation - strategy plans,

feasibility study etc.

Interviews Questionnaires - useful in supporting other methods.

Next component of requirement determination is, Requirements analysis, which includes,

The purpose of this stage is to take an unstructured mass of

requirements data and turn it into a specific, structured requirements specification.

Requirements analysis uses techniques such as DFDs, Data

Modeling and Prototyping.

Requirements analysis is an important communication

between the analyst and the user. Last component of the above is, Requirements specification:
This forms the basis for discussion between the analyst and

the user and should be expressed in precise, clearly defined but understood language.
It also forms the basis for actual systems design The requirements definition phase focuses on three types of

requirements:
The functional requirements consist of the basic functions

that the system must perform. De-tailed functional requirements are defined at the sub-system level.
System properties are non-functional emergent system

properties such as availability, perfor-mance, safety, and so on.

Characteristics that the system must not exhibit. The requirements determination process is the set of

Requirement Determination
Requirements determination involves studying the current business sys-tem to find out how it works and where improvements should be i.e., Systems studies result in an evaluation of

activities that lead to the production of the requirements definition and requirements specification.

Copy Right: Rai University 11.302 79

MANAGING INFORMATION SYSTEM

Therefore, the four basic stages in the requirements

determining process ban be briefed as:

Feasibility study: The study will decide if the proposed

the system require-ments are fully documented and made ready for structuring. In many ways, gathering system requirements is like conducting any investigation. Have you read any of the Sherlock Holmes or similar mystery stories? Do enjoy solving puzzles? From these expe-riences, we can detect some similar characteristics for a good systems analyst during the require-ments determination sub-phases. These characteristics include
Impertinence: You should question everything. You need

system will be cost-effective from a business point of view and if it can be developed given existing budgetary constraints.
Requirements analysis: This is the process of deriving the

system requirements through studying the existing systems, discussions with the customer and potential users, task analysis and opin-ions of experts in the field. This may involve the development of several alternative system models. System prototypes may be developed to understand the requirements.
Requirements definition: It is the activity of translating the

information gathered during analy-sis activity into a document that defines a set of requirements.
Requirements Specification: This is a document

to ask such question as: Are all transactions processed the same way? Could anyone be charged something other than the standard price? Might we someday want to allow and encourage employees to work for more than one department?
Impartiality: Your role is to find the best solution to a

containing all the system specifications in details. The document can act as a contract between the customer and the software developer. The document is subject to several changes during the development process. System Specification, the statement of system requirements, occurs during the first phase of Sys-tem Requirements Analysis. In addition to the brainstorming, interviewing and so on, the activities of the system requirements phase also consist of the following steps: % Establishing system objectives Identifying functions and function interaction Specifying performance for each function Defining an overall operational concept Iterate for various levels of concern Requirements Determination involves studying the current business system to find out how it works and where improvements should be made. Systems studies result in an evaluation of how current methods are working and whether adjustments are necessary or possible. These studies consider both manual and computer methods, as we shall see; they are not merely computer studies. A requirement is a feature that must be included in a new system. It may include a way of capturing or processing data, producing information, controlling a business activity, or supporting management. The determination of requirements thus entails studying the existing system and collecting details about it to find out what these requirements are. The Process of Determining Requirements Once management has granted permission to pursue development of a new system (this was done at the end of the project identification and selection phase of the SDLC) .you begin determining what the new system should do. During requirements determination you and other analysts gather infor-mation on what the system should do from many sources as possible: from users of the current system, from observing user and from reports, forms, and procedures. All of

business problem opportunity. It is not, for example, to find a way to justify the purchase of hardware or to insist on incorporating what users think they want into the system requirements. You must consider issues raised by all parties and find the best organizational solution.
Relax constraints: Assume anything is possible and

eliminate the infeasible. For example, do not accept this statement: Weve always done it that way, have to continue the practice. Traditions are different from rules policies. Traditions probably started for a good reason but, as the organization and its environment change, traditions may turn into habits rather sensible procedures.
Attention to details: Every fact must fit with every other

fact. One element out of place means that the ultimate system will fail at some time. For example an imprecise definition of who a customer is may mean that you purge customer data when a customer has no active orders; yet these past customers vital contacts for future sales.
Reframing Analysis is, in part, a creative process. You must

challenge to look at the organization in new ways. You must consider how each views his or her requirements. You must be careful not to jump conclusion: I worked on a system like that oncethis new system must the same way as the one I built before.

Types of Requirements
When outlining the new system the system analyst should consider the following:
Current Requirements Future Requirements Management Imposed Requirements

Current Requirements
The existing expectation of the system performance, quality, cost and control. This requirement usually from the major design goals and evaluation criteria of the new system acceptance.

Copy Right: Rai University 80 11.302

MANAGING

Future Requirements
Long-term goals. Understanding the future growth and goals and organization would allow the devel-opers to plain the future requirements of the system. The analyst should be forward looking an cater for further growth.

On the other hand, if a bias is introduced or shortcuts are taken in conducting the investigation, requirements anticipation is a problem. We will point out guidelines for structuring an investigation around basic questions to avoid the undesirable consequences requirements anticipation.

INFORMATION

Management Imposed Requirements

Common management imposed requirements are budgets and data lines.

Requirement Investigation
This activity is at the heart of systems analysis. Using a variety tools and skills, analysts study the current system and document its features for further analysis. Requirements investigation relies on the fact-finding techniques discussed in the next section and includes methods for documenting and describing system features.

Classifying Requirements
There are certain defined ways that we can classify our requirements, whether it is important to clarify our requirements or is just a desirable or absolutely optional.

SYSTEM

Mandatory
Demands/requirements that must be meet. Critical.

Requirements Specification
The data produced during the fact-finding investigation are analyzed to determine the requirements specifications, the description of features for stem. This activity has three interrelated parts:
Analysis of Factual Data

Desirable
A wish list. Not as critical. Though it there are meet there would be greater acceptance to the new system

Optional
Less attention requirements.

Activities in Requirements Determination

It is helpful to view requirements determination through the three major activities of requirements anticipation, requirements investigation, and requirements specification (table :A) Activity Requirements Anticipation Description Foreseeing systems characteristics based on previous experience. May cause the analyst to investigate areas and issues that could otherwise be overlooked. May also introduce bias. Study and documentation of the current system, using fact-finding techniques, data flow analysis, and decision analysis. Analysis of data describing the system to determine how well it is performing, what requirements must be met, and strategies for fulfilling them.

The data collected during the fact-finding study and included in flow and decision analysis and docu-mentation are examined to mine how well the system is performing and whether it will the organizations demands.
Identification of Essential Requirements

Features that must be included in a new system, ranging from operational details to performance criteria, are specified.
Selection of Requirements Fulfillment Strategies

The methods that will be used to achieve the stated requirements selected. These form the basis for systems design, which follows requirements specification. All the above three activities are important in the requirement analysis and must be performed cor-rectly by the system analyst.

Requirements Investigation

Deliverables and Outcomes from Requirement Determination

The primary deliverables from requirements determination are the forms of information gathered during the determination process: transcripts of interviews; notes from observation and analysis of documents; analyzed responses from questionnaires; sets of forms, reports, job descriptions, and other documents; and computer generated output such as system prototypes. In short, any thing that the analysis team collects as part of determining system requirements is included in the deliverables resulting from this sub-phase of the systems development Table 1 lists examples of some specific information that might be gathered requirements determination. Table B : Deliverables and Outcomes 1. Information collected from conversations with or observation of users: interview tran-scripts, questionnaire responses, and notes from observation, meeting minutes 2. Existing written information: business mission and strategy statements, sample business forms and reports and computer displays, procedure manuals, job descriptions, training manuals, flowcharts and documentation of existing system, consultant reports

Requirements Specification

Table A :Activities in Requirement Determination

Requirements Anticipation
Having had experience in a particular business area or having encountered systems in an environ-ment similar to the one currently under investigation will influence systems analysts study. They may foreseen the likelihood of certain problems or features and requirements :0 new system. As a result, the features they investigate for the cum system, questions they raise, or methods employed may be based on this familiarity. Requirements anticipation can be a mixed blessing. On the one hand, experience from previous studies can lead to investigation areas that would otherwise go unnoticed by an inexperienced analyst. Having the background to know what to ask or which aspects investigate can be a substantial benefit to the organization.

Copy Right: Rai University 11.302 81

MANAGING INFORMATION SYSTEM

3. Computer based information; results from Joint Application Design sessions, transcripts or Ibs from group support system sessions, CASE repository content and reports of existing system, and displays and reports from system prototypes.

What will be the economic benefit of a successful solution? Is there another source for the solution that you need?

Second Set
This set enable the analyst to gain better understanding of the problem and the customer to voice his/ her PERCEPTION of the SOLUTION

Problems in Requirement Analysis

The Problems of Communication
The requirement analysis is a communication intensive environment. Thus problems inherent in communication would not guarantee a successful requirement analysis.

Examples
How would you characterized as GOOD output that would be generated by a successful solution? What problems will this solution address? Can you show me (describe) the environment in which the solution will be used? Are there special performance issues or constraints that will affect the way the solution is ap-proached?

Some Problems with Communication

Lack of clarity: It is difficult to use language in a precise and unambiguous way without making the documents wordy and therefore difficult to read. Confusions in requirements; Functional, non-functional, system goals and design information may not be clearly distinguished. Requirements amalgamation: several different requirements may be expressed together (in natu-ral language) as a single requirement. Problems faced in Requirement Analysis are centered around the fact that it is a communication intensive activity. Aside from the more physical aspects of noise, e.g. non-conducive environment to communicate with the customer, other forms of noise include things like misinformation (passing of wrong information) or misunderstandings (interpreting a valid piece of information incorrectly).

Third Set
Focuses on the effectiveness of the meeting.

Examples
Are you the right person to answer these questions? Are your answers official Is my question relevant to the problem that you have? Am I asking too many questions? Is there anyone else who can provide me additional information? Is there anything else that I should be asking you?

Other Difficulties
Handling large complex problems Accommodating changes that occur during and after analysis.

Facilitated Application Specification Techniques (FAST)

This can be thought of as a technique that is used after the first meeting is conducted and the basic understanding of the requirements have been answered. It is held in a more formal setting that combines elements of problem solving, negotiation and speci-fication.

Communication Techniques
In the earlier section, we have across various problem that our system analyst face while conducting requirement analysis. To solve such kind of problems, which are identified in the requirements analy-sis, there exists two techniques:
Preliminary meetings or interview Facilitated Application Specification

Team- Oriented approach

Rules for preparation and participation is established An agenda is suggested formal enough to cover important areas and informal to encourage free flow of ideas. Facilitator to control the meeting.

Techniques(FAST)

Preliminary Meetings or Interview

These methods are not as through as an those methods involved in the fact finding phase(questionnaires etc) since they merely close the gap between the analyst and client. Preliminary Meetings or Interview Proposed by Cause and Weinberg To bride the problem between the analyst and the client is through effective first meeting.

Goal is to
Identity problems Propose elements of the solutions Negotiate different approaches to the problem Specify a set of preliminary solutions. In an environment that is conducive.

Benefits
The development of mini-spec (by sub-teams) may uncover new objects, services constraints or performance requirements that will be added to the original list. Sometimes issues that are unresolved would be kept in view and be discussed in the next meeting. Thus FAST provides immediate refinement of requirements and concrete steps towards develop-ment specification.

Sets of Questions
First Set (Context Questions) Basic understanding of the problem Focuses on the customer and overall goals

Examples
Who is behind the request? Who will use the solutions?

Copy Right: Rai University 82 11.302

MANAGING

Requirements Analysis Methods

The are different methods available for requirements analysis which enables an analyst to apply fundamental analysis principles in a systematic fashion.

Each assists the analyst in identifying key information objects ( also called entities or items) and operations ( also called actions or process ). Each assumes that the structure of information is hierarchical. Each requires that the data structure be represented using the sequence, selection and repetition concept constructs for composite data. Each provides a set of steps for mapping hierarchical data structure in to a program structure. Data Structured Systems Development (DSSD) Application Context DSSD first examines that application context, that is, how the data moves between producers and consumers of information from the perspective of one of the producers or consumers. Application Functions They are accessed with a Warnier-Orr like representation that depict information items and what processes must be performed. Application Results Modeled using the Warnier-Orr Technique. This prototype identifies the primary output and the organization of information items that comprises the output. Jackson Systems Development (JSD) Entity step action Identifies entities (people, objects or organizations that a system needs to produce or use information) Entity Structure Step Using Jackson Diagrams, order by time the actions affecting each entity. Initial modeling Step Represents entities and actions as process model; define connections between the model and the real world. Function Step Specify functions that correspond to defined actions System timings Step Assess process-scheduling characteristics Implementation Step Specify hardware and software design. Formal Specification Techniques A formal software specification is a specification expressed in a language whose vocabulary; syntax and semantics are formally defined. The need for formal semantics definition means that the specification language is not of natural language. They are based on mathematics. This method incorporates mathematical techniques into the process. Formal methods allow a software engineer to create a specification that is more complete, consis-tent, and unambiguous than those produced using conventional or object-oriented methods.
83

Common Fundamentals of all Requirements Analysis Methods are

Each supports the fundamental requirements analysis principals. Each creates a hierarchical representation of a system. Each demands a careful consideration of external and internal interfaces. Each provides a foundation for the design and implementation steps that follow.

INFORMATION SYSTEM

Common Characteristics in Requirements Analysis Methods

Mechanism for Information Domain Analysis i.e. All analysis methods address(either directly or indirectly) information flow, information content, and information structure. Approach for functional and/or behavioral representation. All function/behaviors are typically represented by specific notations. Definition of interfaces Interface is derived from an examination of information flow. Mechanism for problem partitioning. Problem partitioning is accomplished by a layering process that allows for representation of informa-tion and function domain at different levels of abstraction. Support for abstraction Abstraction permits one to concentrate on a problem at some level of generalization without regard to irrelevant low-level details. Differences in Requirements Analysis Methods Own point of view, notation and approach Each method for the analysis of computer - based systems has its own point of view its own notation, and its own approach to modeling. Also, each method has its own jargon and terminology. Degree to which these methods establish a firm foundation for design differs greatly. In some cases the analysis model can be mapped directly into a working program, in other cases the analysis model only establishes a starting point and the designer is left to derive the rest. The three broad categories of Requirements Analysis that will be discussed Data Structure-Oriented Methods Formal Methods Data Structure-Oriented Methods Data Structured Systems Development Jackson Systems Development Common Characteristics for all Data Structure-Oriented methods are given below:

Copy Right: Rai University 11.302

MANAGING INFORMATION SYSTEM

Set theory and logic notation are used to create a clear statement of facts (requirements). This mathematical specification can then be analyzed to prove correctness and consistency. Because the specification is created using mathematical notation, it is inherently less ambiguous that informal modes of representation

Features of Formal Specification

Consisting of the following 3 components: A syntax that defines the specific notations with which the specification is represented Semantics that helps to define a universe of objects Indicates how the language represents systems requirements. A set of relationship that defines the rules that indicates which objects satisfy the specification. Other specification language can also develop syntax and semantics to specify states and state transition, events and their state transitions. Advantages
Development of a formal specification provides insights

into and an understanding of the software requirements and the software design.
Formal specification are mathematical entities and may

therefore may be analyzed using mathematical methods.

They may be automatically processed. Software tools can be

made to assist with their development, understanding and development.

Used as a guide to the tester of a component in identifying

appropriate test cases.

Disadvantages Software management is inherently conservative and is

unwilling to adopt new techniques for which payoff is not obvious.

Many software engineers have not been trained in the

techniques required to develop formal specifications.

Systems customers are unlikely to be familiar with formal

specification techniques and hence find it difficult to monitor activities.

There is wide spread ignorance of the practicality of current

specifications techniques and their applicability.

Copy Right: Rai University 84 11.302