STRUCTURED

ANALYSIS AND DESIGN

All system development methodologies lead to a representation of the system
concept in terms of processes and data; however, they vary in terms of whether the
methodology places primary emphasis on business processes or on the data that
supports the business.

In Structured methodologies, a formal step-by-step approach to the SDLC that

moves logically from one phase to the next is adopted such that the representation
of the system is either process-centric or data-centric and not both at the same time.

In Object-oriented methodologies that model real-world systems, processes and data are
so closely related that it is difficult to pick one or the other as the primary focus.
Therefore, the representation of the system is in the form of objects that contains
both data and processes.

Object-oriented approaches to developing information systems, technically speaking,

can use any of the traditional methodologies- waterfall development, parallel
development, phased development, prototyping, and throwaway prototyping. However, the
object-oriented approaches are most associated with a phased development RAD
methodology.

STRUCTURED Process Concerned with capturing, validating, and storing

METHODOLOGY orientation: data and with moving data between each required
step.

Process-centered methodologies focus first on

defining the activities associated with the
system, i.e., the processes. They utilize process
models as the core of the system concept.
Analysts concentrate initially on representing
the system concept as a set of processes
with information flowing into and out of the
processes.

Data orientation: Concerned with understanding relationships

between data so data can be accessed and
summarized in a variety of ways; builds a model
of data that supports a variety of uses.

Data-centered methodologies focus first on

 defining the contents of the data storage
containers and how the contents are
organized. Data-centered methodologies utilize
data models as the core of the system concept.

OBJECT- Object- Object-oriented methodologies attempt to balance

ORIENTED orientation: the focus between processes and data. Object-
METHODOLOGY oriented methodologies utilize the Unified
Modeling Language (UML) to describe the
system concept as a collection of objects
incorporating both data and processes.

ANALYSIS OBJECTIVES
The analysis must achieve three primary objectives:

1. To describe what the customer requires

2. To establish a basis for the creation of a software design [requirement
specification]
3. To define a set of requirements that can be validated once the software
is built.

ANALYSIS PRINCIPLES
All analysis methods are related by a set of operational principles:

Information An information system is built to process data, to transform

domain data from one form to another; that is, to accept input
manipulate it in some way, and produce output Therefore, data
(numbers, text, images, sounds, video, etc.) and control
(events: e.g. password & access) both constitute the information
domain of a problem. The information domain of a problem must be
represented and understood.

Models A model is a graphic representation of a system. The analysis

model, actually a set of models, is the first technical
 representation of a system. The functions that the system is to
perform must be defined. The behavior of the system (as a
consequence of external events) must also be represented.

Partitioning Partitioning decomposes a problem into its constituent parts.

Problems are often too large and complex to be understood as a

whole. For this reason, The models that depict information

function and behavior must be partitioned (divided) in a manner
that uncovers detail in a layered (or hierarchical) fashion.

Constituent parts that should be easily understood and establish

interfaces between the parts so that overall function can be
accomplished.

Views: The analysis process should move from essential information

toward implementation detail. An essential (Logical) view of

system requirements presents the functions to be accomplished
and information to be processed without regard to implementation
details. The implementation (Physical) view of system
requirements presents the real world manifestation of processing
functions and information structures. It shows not only what the
system is or does but also how the system is physically
implemented.

Information domain
The first operational analysis principle requires an examination of the information
domain and the creation of a data model. The information domain contains three
different views of the data and control as each is processed by a computer program:

1. Information content and relationships (the data model)

2. Information flow,
3. Information structure

Information content: represents the individual data and control objects that
constitute some larger collection of information
transformed by the software. For example, the data object,
 paycheck is a composite of a number of important pieces of
data: the payee's name, the net amount to be paid, the
gross pay, deductions, and so forth.

Information flow: represents the manner in which data and control change as
each move through a system.

Information structure: Information structure represents the internal organization

of various data and control items. Are data or control
items to be organized as an n-dimensional table or as a
hierarchical tree structure?

Models
The second and third operational analysis principles require that we build models of
function and behavior.

Functional models: Software transforms information, and in order to accomplish

this, it must perform at least three generic functions:
input, processing, and output. When functional models of an
application are created, the software engineer focuses on
problem specific functions. The functional model begins
with a single context level model (i.e., the name of the
software to be built). Over a series of iterations, more
and more functional detail is provided, until a thorough
delineation of all system functionality is represented.

Behavioral models most software responds to events from the outside world.
This stimulus/response characteristic forms the basis of
the behavioral model. A computer program always exists in
some state—an externally observable mode of behavior (e.g.,
waiting, computing, printing, polling) that is changed only
when some event occurs. e.g., a mouse movement

Roles of models
English narrative descriptions of a system are inefficient because:

1. Language is subject to considerable interpretation

2. Narratives might explain what is known but not necessarily what is unknown
3. Narrative descriptions of a system are often too vague and make it difficult
for the user to grasp how the parts fit together
 4. English is inherently difficult to use where precision is needed.
5. The system life cycle provides very little quality control to ensure accurate
communication from user to analyst. They have no language in common
6. The analyst is quickly overwhelmed with the business and technical details of
the system- the large number of procedures, forms, reports, files, people and
machines can hinder adequate understanding unless tools that will deal with
that complexity are learnt. Much of the time is spent gathering information.
The details are needed and must be available, but the analyst does not have the
tools to structure and control the details.
7. Pictures often communicate better than words

Models created during requirements analysis serve a number of important roles:

1. The model aids the analyst in understanding the information, function, and behavior
of a system, thereby making the requirements analysis task easier and more
systematic.

2. The model becomes the focal point for review and, therefore, the key to a
determination of completeness, consistency, and accuracy of the specifications.

3. The model becomes the foundation for design, providing the designer with an
essential representation of software that can be "mapped" into an implementation
context.

Partitioning
The information, functional, and behavioral domains of software can be partitioned. In
essence, partitioning decomposes a problem into its constituent parts. Conceptually,
we establish a hierarchical representation of function or information and then
partition the uppermost element by:

1. Exposing increasing detail by moving vertically in the hierarchy or

2. Functionally decomposing the problem by moving horizontally in the hierarchy.

To illustrate these partitioning approaches, let us reconsider a Home security system.

STRUCTURED ANALYSIS
System analysis is about understanding situations, not solving problems. Effective
analysts therefore emphasize investigation and questioning to learn how a system
currently operates and to identify the requirements users have for a new or modified
one. The System Requirements Specification is produced at the culmination of the
analysis task. Only after analysts fully understand the systems are they able to
analyze it and assemble recommendations (or specifications) for systems design.

The most widely used structured methodology is SSADM. (SSADM – Structured Systems
Analysis and Design Method)
Structured analysis has the following attributes:

Graphical modeling The analysis employs formal or semi-formal modeling

techniques and notations in building up a specification of the
system which:

1. Captures and satisfies the customer's demands with respect

to the system in question.
2. must be understood by both customer (who wants the
system to be built and pays for the development)
and developer (who is responsible for actually
building it).
3. Provides sufficient information to build the system.

This makes a clear distinction between requirement modeling

and requirement analysis:

 Requirement modeling results in a requirement

specification, the main purpose of which is to allow the
customer and the developer to agree on what is being
developed.

 The main goal of analysis (specifically, requirement

 analysis) is to provide a formal or semi-formal description
of the system being built (in general, the main goal of
analysis is to provide a formal or semi-formal description
of the problem to be solved, while design provides a formal
or semi-formal description of the intended solution).

Partitioning The process is partitioned so that we have a clear picture of the

progression from general to specific in the system flow.

Logical It is logical rather than physical. The elements of system do not

depend on vendor, technology or hardware. They specify in a
precise, concise, and highly readable manner the working of the
system and how it hangs together. The logical system model
familiarizes the user with system characteristics and
interrelationships before implementation.

Environment It calls for a rigorous study of the user area, a commitment that
is often taken lightly in the traditional approach to systems
analysis.

Interleaved Certain tasks that are normally carried out late in the system
processes development life cycle are moved to the analysis phase. For
example, user procedures are documented during rather than later
in implementation.
Requirements Determination
6.2.1 Activities in requirement Determination
6.2.1.1 Requirements Anticipation
6.2.1.2 Requirements Investigation
6.2.1.3 Requirements Specifications
6.2.2 Basic Requirements
6.2.3 Understand the Process
6.2.4 Identify data used and information produced
6.2.5 Determine process timing and volume
6.2.6 Identity controls
6.2.7 User transaction Requirements
6.2.8 User decision Requirements
6.3 Fact – Finding Techniques
6.3.1 Interview
6.3.2 Questionnaire
6.3.3 Record Review
6.3.4 Observation

Analysis strategy development

Requirement elicitation… Requirement Gathering/discovery:

Requirement analysis
Requirements classification and organization
Requirements prioritization and negotiation
Requirement Definition and specification
Requirement Documentation
Requirement validation and verification
Requirement management

REQUIREMENT ENGINEERING
REQUIREMENTS
The manner in which a systems investigation is conducted will determine whether the
appropriate information is gathered. In turn, having the right information influences
the quality of the application that follows. In other words, good system design,
whether developed through the SDLC method, prototyping, or structured methods, begins
by documenting the current system and properly diagnosing systems requirements.

A requirement is defined as "a condition or capability to which a system must

conform". It is simply a statement of what the system must do, what characteristic it
must have or that must be included in a new system. There are many different kinds of
requirements. It may include a way of capturing or processing data, producing
information, controlling a business activity, or supporting management.

Requirements engineering is the process of understanding and defining what services

are required from the system and identifying the constraints on the system’s operation
and development. Requirements engineering is a particularly critical stage of the
software process as errors at this stage inevitably lead to later problems in the
system design and implementation.
The requirements engineering process aims to produce an agreed requirements document
that specifies a system satisfying stakeholder requirements. Requirements are usually
presented at two levels of detail. End-users and customers need a high-level statement
of the requirements; system developers need a more detailed system specification.

There are four main activities in the requirements engineering process:

Feasibility study: An estimate is made of whether the identified

user needs may be satisfied using current
software and hardware technologies. The study
considers whether the proposed system will be
cost-effective from a business point of view
and if it can be developed within existing
budgetary constraints. A feasibility study
should be relatively cheap and quick. The
result should inform the decision of whether
or not to go ahead with a more detailed
analysis.

Requirements elicitation and analysis This is the process of deriving the system
requirements through observation of existing
systems, discussions with potential users and
procurers, task analysis, and so on. This may
involve the development of one or more system
 models and prototypes that will help
understand the system to be specified.

Requirements specification: Requirements specification is the activity of

translating the information gathered during
the analysis activity into a document that
defines a set of requirements. Two types of
requirements may be included in this document.
User requirements are abstract statements of
the system requirements for the customer and
end-user of the system; system requirements
are a more detailed description of the
functionality to be provided.

Requirements validation: This activity checks the requirements for

realism, consistency, and completeness. During
this process, errors in the requirements
document are inevitably discovered. It must
then be modified to correct these problems.

The activities in the requirements process are not simply carried out in a strict
sequence. Requirements analysis continues during definition and specification and new
requirements come to light throughout the process. Therefore, the activities of
analysis, definition, and specification are interleaved. In agile methods, such as
extreme programming, requirements are developed incrementally according to user
priorities and the elicitation of requirements comes from users who are part of the
development team.

FEASIBILITY
CHARACTERISTICS OF REQUIREMENTS

COMPLETE Each requirement must fully describe the functionality to

be delivered. A set of requirement is complete if all
possible states, state changes, inputs, products, and
constraints are described by some requirements.

CORRECT Each requirement must accurately describe the functionality

to be built. That is, they are without error.

REAL/FEASIBLE It must be possible to implement each requirement within

the known capabilities and limitations of the system and
its environment.

CONSISTENT/UNAMBIGUOUS The requirements must not conflict. It must be possible to

satisfy them simultaneously. All readers of the
 requirement statement should arrive at a single, consistent
interpretation

NEEDED/NECESSARY Each requirement should document something that the

customer really need or something that is required for
conformance to an external system requirement or standard.

PRIORITIZED An implementation priority must be assigned to each

requirement, feature or use case to indicate how essential
it is to a particular product release.

VERIFIABLE We must be able to devise a test or other verification

approaches such as inspection or demonstration, to
determine whether the requirement was properly implemented.

TRACEABLE One should be able to link each requirement to its origin

and to the design elements, source code, and test cases
that implement and verify the correct implementation of the
requirement.

MODIFIABLE One must be able to revise the software requirement

specification when necessary and maintain a history of
changes made to each requirement.

TYPES OF REQUIREMENTS:
One way of categorizing them is described as the FURPS+ model, using the
acronym FURPS to describe the major categories of requirements with subcategories as
shown below.

 Functionality
 Usability
 Reliability
 Performance
 Supportability

The "+" in FURPS+ includes additional requirements such as:

 Design constraints
 Implementation requirements
 Interface requirements
 Physical requirements
Functionality  The function of the system
 How the system will execute the function
 Modes of operation
 System update
 Constraints: speed, throughput, response time

Usability  Users and number of users

 Skill level of users
 User Training requirements
 User friendliness of system
 Misuse & abuse of system

Reliability

Performance

Supportability  Design change incorporation

 Maintenance & error correction
 Efficiency measures in resource usage & response time.
 Ease of system relocation

Documentation:
 Required quantity & quality of documentation
 Documentation format: online, book or both
 Type of documentation
 Audience

Design
constraints

Implementation
requirements

Interface  Source of input

requirements  Destination of input
 Data format

Physical  Location of equipment

requirements  Number of locations
 Environmental restrictions: Temperature, magnetic interference
…

Data:  Data format for input & output

 Accuracy & precision
 System data flow
 Frequency & duration of data retention, input & output

Resources:  Required personnel, materials or other resources.

 Skills
 Physical space
 Power, heating & air conditioning
 Financial constraints

Security:  Access control

 Data protection & back-up
 Software environment
 Fire, water damage or theft
Quality  Requirements for reliability, availability, security, and
Assurance: other quality attributes.
 Fault detection and isolation
 Failures
 Design change incorporation
 Maintenance & error correction
 Efficiency measures in resource usage & response time.
 Ease of system relocation

LEVELS OF REQUIREMENTS

Software requirements are defined at various levels of detail and granularity.

Requirements at different levels of detail also mean to serve different purposes.

Domain requirements: Domain requirements are derived from the application

domain of the system rather than from the specific
needs of system users. They may be new functional
requirements in their own right, constrain existing
functional requirements, or set out how particular
computations must be carried out. The problem with
domain requirements is that software engineers may
not understand the characteristics of the domain in
which the system operates. They often cannot tell
 whether or not a domain requirement has been missed
out or conflicts with other requirements.

Business: These are used to state high-level business objective

of the organization or customer requesting the system
or product. During analysis, requirements are written
from the perspective of the businessperson, and they
focus on the “what” of the system. They focus on
business user needs, so they usually are called
business requirements. They are used to document main
system features and functionalities without going
into details. They are captured in a document
describing the project vision and scope

User: User requirements add further detail to the business

requirements. They are called user requirements
because they are written from the user's perspective
and the focus of the user requirements describe tasks
the user must be able to accomplish in order to
fulfill the above stated business requirement. They
are captured in the requirement definition document.

System/Functional: These are statements of services the system should

provide, how the system should react to particular
inputs, and how the system should behave in
particular situations. In some cases, the functional
requirements may also explicitly state what the
system should not do.

This brings in the system's view and defines from the

system's perspective the functionality the developers
must build into the product t enable users to
accomplish their tasks stated in the user
requirements-thereby satisfying the business
requirements.

In design, business requirements evolve to become

more technical, and they describe “how” the system
will be implemented. Requirements in design are
written from the developer’s perspective, and they
usually are called system requirements.
 There is no black-and-white line dividing a business
requirement and a system requirement—and some
companies use the terms interchangeably. The
important thing to remember is that a requirement is
a statement of what the system must do, and
requirements will change over time as the project
moves from analysis to design to implementation.
Requirements evolve from detailed statements of the
business capabilities that a system should have to
detailed statements of the technical way in which the
capabilities will be implemented in the new system.

Requirements can be either functional or

nonfunctional in nature. A functional requirement
relates directly to a process the system has to
perform or information it needs to contain. For
example, requirements that state that the system must
have the ability to search for available inventory or
to report actual and budgeted expenses are functional
requirements.

All functional requirements must derive from user

requirement, which must themselves be aligned with
the business requirements.

Non-Functional: These are constraints on the services or functions

offered by the system. They include timing
constraints, constraints on the development process,
and constraints imposed by standards.

The requirement document should not only describe the

functionality needed and provided by the system, but
it must also specify the constraints under
which it must operate. Constraints are restrictions
that are placed on the choices available to the
developer for design and construction of the
software product. These kinds of requirements are
called Non-functional requirements. These are used to
describe external system interfaces, design and
implementation constraints, quality and performance
 attributes. These also include regulations,
standards, and contracts to which the product must
conform.

Non-functional requirements play a significant role

in the development of the system. If not captured
properly, the system May not fulfill some of the
business needs and may collapse. They dictate how the
system architecture and framework would be. As an
example, we can require the software to run on Sun
Solaris Platform. Now it is clear that if the non-
functional requirement was not captured initially and
the entire set of functionality was built to run on
Windows, the system would be useless for the client.

Nonfunctional requirements refer to behavioral

properties that the system must have, such as
performance and usability. The ability to access the
system using a Web browser would be considered a
nonfunctional requirement. Nonfunctional requirements
may influence the rest of analysis but often do so
only indirectly; nonfunctional requirements are
primarily used in design when decisions are made
about the user interface, the hardware and software,
and the system’s underlying physical architecture.

Non-functional requirements arise through user needs,

because of budget constraints, organizational
policies, the need for interoperability with other
software or hardware systems, or external factors
such as safety regulations or privacy legislation,
hardware systems, or external factors such as safety
regulations or privacy legislation

Types of non-functional requirement

Product These requirements specify or constrain the behavior of the

requirements system. Examples include performance requirements on how fast the
system must execute and how much memory it requires, reliability
requirements that set out the acceptable failure rate, security
requirements, and usability requirements.
Organizational These requirements are broad system requirements derived from
requirements policies and procedures in the customer’s and developer’s
organization. Examples include operational process requirements
that define how the system will be used, development process
requirements that specify the programming language, the
development environment or process standards to be used, and
environmental requirements that specify the operating environment
of the system.

External This broad heading covers all requirements that are derived from
requirements factors external to the system and its development process. These
may include regulatory requirements that set out what must be
done for the sys-tem to be approved for use by a regulator, such
as a central bank; legislative requirements that must be
followed to ensure that the system operates within the law; and
ethical requirements that ensure that the system will be
acceptable to its users and the general public.
Operational The physical and technical  The system should be able to fit
environments in which the in a pocket or purse.
system will operate  The system should be able to
integrate with the existing
inventory system
 The system should be able to work
on any Web browse

Performance The speed, capacity, and  Any interaction between the user
reliability of the system and the system should not exceed 2
seconds
 The system should receive updated
inventory information every 15
minutes
 The system should be available for
use 24 hours per day, 365 days per
year v

Security Who has authorized access to  Only direct managers can see
the system under what personnel records of staff.
circumstances  Customers can only see their order
history during business hours.

Cultural and Cultural, political factors  The system should be able to

Political and legal requirements that distinguish between Nigerian and
affect the system Ghanaian currency.
 Company policy says that we only
buy computers from Dell
 Country managers are permitted to
authorize customer user interfaces
within their units
 The system shall comply with
insurance industry standards

Metrics for specifying non-functional requirements

Property Measure

Speed  Processed transactions/second

 User/event response time
 Screen refresh time

Size  Mbytes
  Number of ROM chips

Ease of use  Training time

 Number of help frames

Reliability  Mean time to failure

 Probability of unavailability
 Rate of failure occurrence
 Availability

Robustness  Time to restart after failure

 Percentage of events causing failure
 Probability of data corruption on failure

Portability  Percentage of target dependent statements

 Number of target systems

In reality, the distinction between different types of requirement is not as clear-cut

as these simple definitions suggest. A user requirement concerned with security, such
as a statement limiting access to authorized users, may appear to be a non-functional
requirement. However, when developed in more detail, this requirement may generate
other requirements that are clearly functional, such as the need to include user
authentication facilities in the system. This shows that requirements are not
independent and that one requirement often generates or constrains other requirements.
Non-functional requirements such as reliability, safety, and confidentiality
requirements are particularly important for critical systems.

It must be noted that during the requirement process, we are in the definition phase
of the software development where the focus is on what and not how. Therefore,
requirements must not include design or implementation details

Viewpoints and Concerns

Non-functional requirements often conflict and interact with other functional or non-
functional requirements. It is difficult, in practice, to separate functional and non-
functional requirements in the requirements document. If the non-functional
requirements are stated separately from the functional requirements, the
relationships between them may be hard to understand. A user requirement
concerned with security, such as a statement limiting access to authorized users, may
appear to be a non-functional requirement. However, when developed in more detail,
this requirement may generate other requirements that are clearly functional
In most large systems, the relationships between the requirements and the program
components are complex. A single requirement may be implemented by a number of
components and each component may include elements of several requirements (functional
or non-functional). In practice, this means that implementing a change to the
requirements may involve understanding and changing several components. Alternatively,
a component may provide some core functionality but also include code that implements
several system requirements.

A viewpoint is (way of collecting and organizing) a set of requirements from a group

of stakeholders who have something in common. Viewpoints reflect the distinct
functionality that is required by different stakeholder groups.

Viewpoints might come from end-users, managers, stakeholders, application domain,

other systems that interact with the system being specified etc. All of these must be
considered during the requirements elicitation process.

These different requirements sources can all be represented as system viewpoints

with each viewpoint showing a subset of the requirements for the system. Each
viewpoint therefore includes a set of system requirements. Different viewpoints on a
problem see the problem in different ways. However, their perspectives are not
completely independent but usually overlap so that they have common requirements.

These viewpoints can be used:

1. To structure both the discovery and the documentation of the system
requirements
2. For identifying the people who can provide information about their requirements
and structure the requirements for analysis.

It is hard to pin down what is actually meant by a concern. Sometimes it is defined as

a functional notion (i.e., a concern is some element of functionality in a system).
Alternatively, it may be defined very broadly as ‘any piece of interest or focus in a
program’. Neither of these definitions is particularly useful in practice. Concerns
certainly are more than simply functional elements but the more general definition is
so vague that it is practically useless. Most attempts to define concerns are
problematic because they attempt to relate concerns to programs.

Concerns are reflections of the system requirements and priorities of stakeholders in

the system. System performance may be a concern because users want to have a rapid
response from a system; some stakeholders may be concerned that the system should
include particular functionality; companies who are supporting a system may be
concerned that it is easy to maintain. A concern can therefore be defined as something
that is of interest or significance to a stakeholder or a group of stakeholders.

There are several different types of stakeholder concern:

Functional concerns Related to the specific functionality to be included in a

system. For example, in a train control system, a specific
functional concern is train braking.

Quality of service Related to the non-functional behavior of a system. These

concerns include characteristics such as performance, reliability,
and availability.

Policy concerns Related to the overall policies that governs the use of a
system. Policy concerns include security and safety
concerns and concerns related to business rules.

System concerns Related to attributes of the system as a whole, such as its

maintainability or its configurability.

Organizational concerns Related to organizational goals and priorities. These

include producing a system within budget, making use of
existing software assets, and maintaining the reputation of
the organization

Core and cross-cutting concerns

The core concerns of a system are those functional concerns that relate to its primary
purpose. Therefore, for an Internet banking system, this system has requirements
relating to new customers such as credit checking and addresses verification. It also
has requirements related to the management of existing customers and the management of
customer accounts. All of these are core concerns that are associated with the
system’s primary purpose—the provision of an Internet banking service.
However, the system also has security requirements based on the bank’s security
policy, and recovery requirements to ensure that data is not lost in the event of a
system failure. These are cross-cutting concerns as they may influence the
implementation of all of the other system requirements.

In addition to core concerns, large systems also have secondary functional concerns.
These may involve functionality that shares information with the core concerns, or
which is required so that the system can satisfy its non-functional requirements.

In addition to these secondary concerns, other concerns such as quality of service and
organizational policies reflect essential system requirements. In general, these are
system concerns—they apply to the system as a whole rather than to individual
requirements or to the realization of these requirements in a program. These are
called cross-cutting concerns to distinguish them from core concerns. Secondary
functional concerns may also be cross-cutting although they do not always cross-cut
the entire system; rather, they are associated with groupings of core concerns that
provide related functionality.

Programming language abstractions, such as procedures and classes, are the mechanism
that you normally use to organize and structure the core concerns of a system.
However, the implementation of the core concerns in conventional programming languages
usually includes additional code to implement the cross-cutting, functional, quality
of service, and policy concerns. This leads to two undesirable phenomena: tangling and
scattering

Tangling and Scattering

Tangling occurs when a module in a system includes code that implements
different system requirements.
The figure is an implementation of the put operation that adds an item for the buffer.
However, if the buffer is full, it has to wait until a corresponding get operation
removes an item from the buffer. The details are unimportant; essentially the wait ()
and notify () calls are used to synchronize the put and get operations.

The code supporting the primary concern (in this case, putting a record into the
buffer), is tangled with code implementing synchronization. Synchronization code,
which is associated with the secondary concern of ensuring mutual exclusion, has to be
included in all methods that access the shared buffer. Code associated with the
synchronization concern is shown as shaded code

Scattering occurs when the implementation of a single concern (a logical requirement

or set of requirements) is scattered across several components in a program. This is
likely to occur when requirements related to secondary functional concerns or policy
concerns are implemented.

The figure illustrated this: This diagram shows examples of three classes that might
be included in a patient record system along with some of the core methods for
managing patient information. The shaded area shows the methods that are required to
implement the secondary statistics concern. You can see that this statistics concern
is scattered throughout the other core concerns.

Problems with scattering and tangling occur when the initial system requirements
change. For example, say new statistical data had to be collected in the patient
record system. The changes to the system are not all located in one place and so you
have to spend time looking for the components in the system that have to be changed.
You then have to change each of these components to incorporate the required changes.
This may be expensive because of the time required to analyze the components and then
make and test the changes. There is always the possibility that you will miss some
code that should be changed and so the statistics will be incorrect.
Furthermore, as several changes have to be made, this increases the chances that you
will make a mistake and introduce errors into the software.

Cross-cutting viewpoints and concerns

However, there are also requirements which cross-cut all viewpoints, as shown below:

This diagram shows that viewpoints may be of different types but cross-cutting
concerns (such as regulation, dependability, and security) generate requirements that
may impact on all of the system viewpoints.

When designing a system that supports different stakeholder concerns, think of a

system that supports different stakeholder concerns as a core system plus extensions.

Ext 1 Ext 2 Ext 3

Ext 4 Core system Ext 5

The core system is a set of system features that implements the essential purpose of a
system. Therefore, if the purpose of a particular system is to maintain information on
patients in a hospital, then the core system provides a means of creating, editing,
managing, and accessing a database of patient records.

System purpose Core system functions Extended functions

Maintain information  Creating  Confidentiality

on patients  Editing  Access Control
 Managing  Encryption
 Accessing

The extensions to the core system reflect additional stakeholder concerns, which must
be integrated with the core system. For example, it is important that a medical
information system maintains the confidentiality of patient information, so one
extension might be concerned with access control, another with encryption, etc.

Extensions always add some kind of functionality or additional features to the core
system. Aspects are a way to implement these extensions and they can be com-posed with
the core system functionality using the weaving facilities in the aspect-oriented
programming environment

Types of extensions

Secondary functional These add additional capabilities to the functionality provided

extensions in the core system. For instance, the production of reports on
the drugs prescribed in the previous month would be a secondary
functional extension to a patient information system.
Policy extensions These add functional capabilities to support organizational
policies. Extensions that add security features are examples of
policy extensions.

QoS extensions These add functional capabilities to help attain the quality of
service requirements that have been specified for the system.
For example, an extension might implement a cache to reduce the
number of database accesses or automated backups for recovery
in the event of a system failure.

Infrastructure These extensions add functional capabilities to support the

extensions implementation of a system on some specific implementation
platform. For example, in a patient information system,
infrastructure extensions might be used to implement the
interface to the underlying database management system. Changes
to this interface can be made by modifying the associated
infrastructure extensions

To develop a system that is organized in the style shown in Figure above, you should
identify requirements for the core system plus the requirements for the system
extensions.

A viewpoint-oriented approach to requirements engineering organizes the requirements

according to stakeholder viewpoint, you can then analyze them to discover related
requirements that appear in all or most viewpoints. These represent the core
functionality of the system. Other viewpoint requirements may be requirements that are
specific to that viewpoint. These can be implemented as extensions to the core
functionality

For example, imagine that you are developing a software system to keep track of
specialized equipment used by the emergency services. Equipment is located at
different places across a region or state and, in the event of an emergency such as a
flood or earthquake; the emergency services use the system to discover what equipment
is available close to the site of the problem. The table below outlines requirements
from three possible viewpoints for such a system
You can see from this example that stakeholders from all of the different view-points
need to be able to find specific items of equipment, browse the equipment available at
each location, and check in/check-out equipment from the store. These are therefore
requirements for the core system.

The secondary requirements support the more specific needs of each viewpoint. There
are secondary requirements for system extensions supporting equipment use, management,
and maintenance. The secondary functional requirements that are identified from any
one viewpoint do not, necessarily, cross-cut the requirements from other viewpoints.
For example, only the maintenance viewpoint is interested in completing maintenance
records. These requirements reflect the needs of that viewpoint and those concerns may
not be shared with other viewpoints.

In addition to the secondary functional requirements, however, there are cross-

cutting concerns that generate requirements of importance to some or all
viewpoints. These often reflect policy and quality of service requirements that apply
to the system as a whole. These are non-functional requirements such as requirements
for security, performance, and cost. In the equipment inventory system, an example of
a cross-cutting concern is system availability. Emergencies may happen with little or
no warning. Saving lives may require essential equipment to be deployed as quickly as
possible. Therefore, the dependability requirements for the equipment inventory
system include requirements for a high level of system availability. Some examples of
these dependability requirements, with associated rationale, are shown below.
Using these requirements, you can then identify extensions to the core functionality
for transaction logging and status reporting. These make it easier to identify
problems and switch to a backup system.

The outcome of the requirements engineering process should be a set of requirements

that are structured around the notion of a core system plus extensions. For example,
in the inventory system, examples of core requirements might be:

C.1 The system shall allow authorized users to view the description of
any item of equipment in the emergency services inventory.

C.2 The system shall include a search facility to allow authorized

users to either individual inventories or the complete inventory
for a specific item of equipment or a specific type of equipment.
The system may also include an extension that is intended to
support equipment procurement and replacement.

Requirements for this extension might be:

E1.1 It shall be possible for authorized users to place orders with

accredited suppliers for replacement items of equipment.

E1.1.1 When an item of equipment is ordered, it should be allocated to a

specific inventory and flagged in that inventory as ‘on order’.

As a general rule, you should avoid having too many concerns or extensions to the
system. These simply confuse the reader and may lead to premature design. This limits
the freedom of designers and may result in a system design that cannot meet its
quality of service requirements.
PRACTICALS

Analysis strategy development

[Planning]

Requirements determination 1. Anticipation

2. Investigation, elicitation and
gathering

Requirements analysis 1. Discovery

2. Classification and organization
3. Prioritization and negotiation

Requirements definition and

Specification

Requirement Documentation

Requirement validation and

verification

Requirement management
ANALYSIS STRATEGY DEVELOPMENT

Before the project team can determine what requirements are appropriate for a given
system, they need to have a clear vision of the kind of system that will be created,
and the level of change that it will bring to the organization.

The basic process of analysis is divided into three steps:

1. Understanding the as-is system
2. Identifying improvements
3. Developing requirements for the to-be system

Sometimes the first step (i.e., understanding the as-is system) is skipped or done in
a cursory manner. This happens when no current system exists, if the existing system
and processes are irrelevant to the future system, or if the project team is using a
RAD or agile development methodology in which the as-is system is not emphasized.

Users of traditional design methods such as waterfall and parallel development

typically spend significant time understanding the as-is system and identifying
improvements before moving to capture requirements for the to-be system. However,
newer RAD, agile, and object-oriented methodologies, such as phased development,
prototyping, throwaway prototyping, and extreme programming focus almost exclusively
on improvements and the to-be system requirements, and they spend little time
investigating the current as-is system.

ANALYSIS STRATEGY DEVELOPMENT TECHNIQUES

Business process automation, business process improvement, or business process
reengineering—help the analyst lead users through the analysis steps so that the
vision of the system can be developed

The choice of technique used is based on the amount of change the system is meant to
create in the organization.

BPA is based on small change that improves process

BUSINESS PROCESS AUTOMATION
efficiency
BPI creates process improvements that lead to
BUSINESS PROCESS IMPROVEMENT
better effectiveness
BPR revamps the way things work so that the
BUSINESS PROCESS REENGINEERING
organization is transformed on some level
BPE creates a new system when no current system
BUSINESS PROCESS ENGINEERING
exists
 PRODUCT ENGINEERING PE

To move the users “from here to there,” an analyst needs strong critical thinking
skills. Critical thinking is the ability to recognize strengths and weaknesses and
recast an idea in an improved form, and they are needed to really understand issues
and develop new business processes. These skills are needed to thoroughly examine the
results of requirements gathering, to identify business requirements, and to translate
those requirements into a concept for the new system.
Business Process Automation
Business process automation (BPA) means leaving the basic way in which the
organization operates unchanged, and using computer technology to do some of the work.
BPA can make the organization more efficient but has the least impact on the business.

BPA projects spend a significant time understanding the current as-is system before
moving on to improvements and to-be system requirements. Problem analysis and root
cause analysis are two popular BPA techniques.

BPA techniques

Problem analysis
It is an act of reasoning and analysis to find "the problem behind the problem". It
means asking the users and managers to identify problems with the as-is system and to
describe how to solve them in the to-be system. Problem analysis is done to understand
problems, initial stakeholder needs, and propose high-level solutions.

During problem analysis, agreement is gained on the real problem(s), and who the
stakeholders are. Also, you define what from a business perspective are the
boundaries of the solution, as well as business constraints on the solution.
You should also have analyzed the business case for the project so that there is a
good understanding of what return is expected on the investment made in the system
being built.

Most users have a very good idea of the changes they would like to see, and most will
be quite vocal about suggesting them. Most changes tend to solve problems rather than
capitalize on opportunities, but this is possible, too. Improvements from problem
analysis tend to be small and incremental (e.g., provide more space in which to type
the customer’s address; provide a new report that currently does not exist). This type
of improvement often is very effective at improving a system’s efficiency or ease of
use. However, it often provides only minor improvements in business value—the new
system is better than the old, but it may be hard to identify significant monetary
benefits from the new system

Root Cause Analysis

The ideas produced by problem analysis tend to be solutions to problems. All solutions
make assumptions about the nature of the problem, assumptions that may or may not be
valid. Users (and most people in general) tend to jump quickly to solutions without
fully considering the nature of the problem.
Sometimes the solutions are appropriate, but many times they address a symptom of the
problem, not the true problem or root cause itself. For example, suppose you notice
that a light bulb is burned out above your front door. You buy a new bulb, get out a
ladder, and replace the bulb. A month later, you see that the same bulb is burnt out,
so you buy a new bulb, haul out the ladder, and replace it again. This repeats itself
several times. At this point, you have two choices. You can buy a large package of
light bulbs and a fancy light bulb changer on a long pole so you don’t need to haul
the ladder out each time (thus saving a lot of trips to the store for new bulbs and a
lot of effort in working with the ladder). Or you can fix the light fixture that is
causing the light to burn out in the first place. Buying the bulb changer is treating
the symptom (the burnt-out bulb), while fixing the fixture is treating the root cause

In the business world, the challenge lies in identifying the root cause. The solutions
that users propose (or systems that analysts think of) may either address symptoms or
root causes, but without a careful analysis, it is difficult to tell which one.

Root cause analysis focuses on problems, not solutions. The analyst starts by having
the users generate a list of problems with the current system, and then prioritize the
problems in order of importance. Then starting with the most important, the users
and/or the analysts generate all the possible root causes for the problems. Each
possible root cause is investigated (starting with the most likely or easiest to
check) until the true root cause(s) are identified. If any possible root causes are
identified for several problems, those should be investigated first, because there is
a good chance they are the real root causes influencing the symptom problems.

In our light bulb example, there are several possible root causes. A decision tree
sometimes helps with the analysis. As the Figure shows, there are many possible root
causes, so buying a new fixture may or may not address the true root cause. In fact,
buying a light-bulb changer may actually address the root cause. The key point in root
cause analysis is to always challenge the obvious.
Business Process Improvement
Business process improvement (BPI) means making moderate changes to the way in which
the organization operates to take advantage of new opportunities offered by technology
or to copy what competitors are doing. BPI can improve efficiency (i.e., doing things
right) and improve effectiveness (i.e., doing the right things).

BPI projects also spend time understanding the as-is system, but much less time than
BPA projects; their primary focus is on improving business processes, so time is spent
on the as-is only to help with the improvement analyses and the to-be system
requirements.

BPI techniques
Three popular BPI activities are:

1. Duration analysis,
2. Activity-based costing
3. Information benchmarking

Duration Analysis (Time-based costing)

Duration analysis requires a detailed examination of the amount of time it takes to
perform each process in the current as-is system. The analysts begin by determining
the total amount of time it takes, on average, to perform a set of business processes
for a typical input. They then time each of the individual steps (or sub-processes) in
the business process. The time to complete the basic steps are then totaled and
compared to the total for the overall process. When there is a significant difference
between the two, this indicates that this part of the process is badly in need of a
major overhaul.

For example, suppose that the analysts are working on a home mortgage system and
discover that on average, it takes thirty days for the bank to approve a mortgage.
They then look at each of the basic steps in the process (e.g., data entry, credit
check, title search, appraisal, etc.) and find that the total amount of time actually
spent on each mortgage is about eight hours. This is a strong indication that the
overall process is badly broken, because it takes thirty days to perform one day’s
work.

Process fragmentation, integration and parallelization

These problems likely occur because the process is badly fragmented. Many different
people must perform different activities before the process finishes. In the mortgage
example, the application probably sits on many peoples’ desks for long periods of time
before it is processed. Processes in which many different people work on small parts
of the inputs are prime candidates for process integration or parallelization.

Process integration means changing the fundamental process so that fewer people work
on the input, which often requires changing the processes
and retraining staff to perform a wider range of duties.

Process parallelization means changing the process so that all the individual steps
are performed at the same time. For example in the mortgage
application example, there is probably no reason that the
credit check cannot be performed at the same time as the
appraisal and title check

Activity-Based Costing
Activity-based costing is a similar analysis that examines the cost of each major
process or step in a business process rather than the time taken. The analysts
identify the costs associated with each of the basic functional steps or processes,
identify the most costly processes, and focus their improvement efforts on them.
Assigning costs is conceptually simple. You just examine the direct cost of labor and
materials for each input. Materials costs are easily assigned in a manufacturing
process, while labor costs are usually calculated based on the amount of time spent on
the input and the hourly cost of the staff. However, as you may recall from a
managerial accounting course, there are indirect costs such as rent, depreciation, and
so on that also can be included in activity costs.

Informal Benchmarking
Benchmarking refers to studying how other organizations perform a business process in
order to learn how your organization can do something better. Benchmarking helps the
organization by introducing ideas that employees may never have considered, but have
the potential to add value.

Informal benchmarking is fairly common for “customer-facing” business processes (i.e.,

those processes that interact with the customer). With informal benchmarking, the
managers and analysts think about other organizations, or visit them as customers to
watch how the business process is performed. In many cases, the business studied may
be a known leader in the industry or simply a related firm. For example, suppose the
team is developing a Web site for a car dealer. The project sponsor, key managers, and
key team members would likely visit the Web sites of competitors, as well as those of
others in the car industry (e.g., manufacturers, accessories suppliers) and those in
other industries that have won awards for their Web sites

Business Process Reengineering

Business process reengineering (BPR) means changing the fundamental way in which the
organization operates— completely eliminating the current way of doing business and
making major changes to take advantage of new ideas and new technology.

BPR projects spend little time understanding the as-is, because their goal is to focus
on new ideas and new ways of doing business.

BPR techniques
1. Outcome analysis
2. Technology analysis
3. Activity elimination

Outcome Analysis
Outcome analysis focuses on understanding the fundamental outcomes that provide value
to customers. It determines what the organization’s products and services enable the
customers to do and what effective and efficient ways they could enable the customer
to do such things.
Technology Analysis
Many major changes in business over the past decade have been enabled by new
technologies. Technology analysis therefore starts by having the analysts and managers
develop a list of important and interesting technologies. Then the group
systematically identifies how each and every technology could be applied to the
business process and identifies how the business would benefit.

Activity Elimination Activity

The analysts and managers work together to identify how the organization could
eliminate each and every activity in the business process, how the function could
operate without it, and what effects are likely to occur.

Business Process Engineering

Business process engineering is one approach for creating an overall plan for
implementing the computing architecture. The goal of business process engineering
(BPE) is to define architectures that will enable a business to use information
effectively.

This is done when no current system exists, if the existing system and processes are
irrelevant to the future system, or if the project team is using a RAD or agile
development methodology in which the as-is system is not emphasized.

Three different architectures must be analyzed and designed within the context of
business objectives and goals:

1. Data architecture
2. Applications architecture
3. Technology infrastructure

The data architecture: provides a framework for the information needs of a

business or business function. The individual
building blocks of the architecture are the data
objects that are used by the business. A data object
contains a set of attributes that define some aspect,
quality, characteristic, or descriptor of the data
that are being described.

Once a set of data objects is defined, their

relationships are identified. A relationship
indicates how objects are connected to one another.
 The data objects (there may be hundreds or even
thousands for a major business activity) flow between
business functions, are organized within a database,
and are transformed to provide information that
serves the needs of the business.

The application architecture: encompasses those elements of a system that transform

objects within the data architecture for some
business purpose. They include the system of programs
(software) that performs this transformation, the
role of people (who are information transformers and
users) and business procedures that have not been
automated.

The technology infrastructure: provides the foundation for the data and application
architectures. The infrastructure encompasses the
hardware and software that are used to support the
application and data. This includes computers,
operating systems, networks, telecommunication links,
storage technologies, and the architecture (e.g.,
client/server) that has been designed to implement
these technologies.

BPE techniques
1. Information strategy planning (ISP)
2. Business area (domain) analysis (BAA)
3. Business system design (BSD)
4. Construction and integration

Information strategy planning (ISP)

ISP views the entire business as an entity and isolates the domains of the business
(e.g., engineering, manufacturing, marketing, finance, sales) that are important to
the overall enterprise. ISP defines the data objects that are visible at the
enterprise level, their relationships, and how they flow between the business domains

Business area analysis

BAA is concerned with identifying in detail data (in the form of entity [data object]
types) and function requirements (in the form of processes) of selected business areas
[domains] identified during ISP and ascertaining their interactions (in the form of
matrices). It is only concerned with specifying what is required in a business area

As the system engineer begins BAA, the focus narrows to a specific business domain.
BAA views the business area as an entity and isolates the business functions and
procedures that enable the business area to meet its objectives and goals. BAA, like
ISP, defines data objects, their relationships, and how data flow. But at this level,
these characteristics are all bounded by the business area being analyzed. The outcome
of BAA is to isolate areas of opportunity in which information systems may support the
business area.

Business system design (BSD)

Once an information system has been isolated for further development, BPE makes a
transition into software engineering. By invoking a business system design (BSD) step,
the basic requirements of a specific information system are modeled and these
requirements are translated into data architecture, applications architecture, and
technology infrastructure.

Construction and integration

Construction and integration focuses on implementation detail. The architecture and
infrastructure are implemented by constructing an appropriate database and internal
data structures, by building applications using software components, and by selecting
appropriate elements of a technology infrastructure to support the design created
during BSD. Each of these system components must then be integrated to form a complete
information system or application. The integration activity also places the new
information system into the business area context, performing all user training and
logistics support to achieve a smooth transition.

VIEW BUSINESS PROCESS OUTPUT

ENGINEERING

World BUSINESS ENTERPRISE INFORMATION STRATEGY BUSINESS AREAS (DOMAINS)

View PLANNING (ISP)
 BUSINESS  Engineering
 Manufacturing
 Education
 marketing
 Finance
 Sales

Domain BUSINESS AREA (DOMAIN) BUSINESS AREA INFORMATION SYSTEM COMPONENTS

(DOMAIN) ANALYSIS
view  Data objects
 Engineering (BAA)
 Manufacturing  Relationships between data objects
 Education  Data flow
 marketing  Business functions and procedures
 Finance
 Sales

SOFTWARE ENGINEERING:
Element INFORMATION SYSTEM SYSTEM ARCHITECTURE
COMPONENTS
view BUSINESS SYSTEM DESIGN  Data architecture
(BSD)
 Data objects  Applications architecture
 Relationships between  Technology infrastructure
data objects
 Data flow
 Business functions and
procedures

SOFTWARE ENGINEERING:
Detailed INFRASTRUCTURE
view CONSTRUCTION AND New Information System
INTEGRATION
 Database
  Internal Data Structures
 Applications
 Technology Infrastructure

Product engineering
The goal of product engineering is to translate the customer’s desire for a set of
defined capabilities into a working product. To achieve this goal, product engineering
—like business process engineering—must derive architecture and infrastructure. The
architecture encompasses four distinct system components: software, hardware, data
(and databases), and people. A support infrastructure is established and includes the
technology required to tie the components together and the information (e.g.,
documents, CD-ROM, video) that is used to support the components

PE techniques
1. Requirements engineering
2. Component engineering
3. Analysis & design modeling
4. Construction & integration

Requirements engineering
The world view is achieved through requirements engineering. The overall requirements
of the product are elicited from the customer. These requirements encompass
information and control needs, product function and behavior, overall product
performance, design and interfacing constraints, and other special needs. Once these
requirements are known, the job of requirements engineering is to allocate function
and behavior to each of the four components noted earlier.

System component engineering

System component engineering is actually a set of concurrent activities that address
each of the system components separately: software engineering, hardware engineering,
human engineering, and database engineering. Each of these engineering disciplines
takes a domain-specific view, but it is important to note that the engineering
disciplines must establish and maintain active communication with one another. Part of
the role of requirements engineering is to establish the interfacing mechanisms that
will enable this to happen

Analysis and design modeling

The element view for product engineering is the engineering discipline itself applied
to the allocated component. The analysis step models allocated requirements into
representations of data, function, and behavior. Design maps the analysis model into
data, architectural, interface, and software component-level designs.

Construction and integration

Construction and integration activities that encompass code generation, testing, and
support steps.

VIEW PRODUCT ENGINEERING OUTPUT

World REQUIREMENT ENGINEERING: CAPABILITIES/COMPONENTS

THE COMPLETE
View
PRODUCT
(Information System)  Requirements Elicitation  Hardware
 Requirements Analysis  Software
 And Negotiation  Data (and databases)
 Requirements  People
Specification
 System Modeling
 Requirements Validation
 Requirements
Management

Domain CAPABILITY/COMPONENT SYSTEM COMPONENT PROCESSING REQUIREMENTS

ENGINEERING
view  Data
 Hardware
 Function
 Software  Software Engineering
 Behavior
 Data (and databases)  Hardware Engineering
 Human Engineering
 People
 Database Engineering


SYSTEM ANALYSIS AND

Element SPECIFICATIONS:
DESIGN
view  Data MODELING  Data
 Function  Function
 Behavior  Behavior

DESIGN:
 Data designs
 Architectural designs
 Interface designs
 Software component-level
designs

 Specifications CONSTRUCTION AND  PRODUCT

Detailed INTEGRATION
 Design (CBIS)
view

REQUIREMENT ENGINEERING:
REQUIREMENTS DETERMINATION
Requirements determination involves studying the current business system to find out
how it works and where improvements should be made. The purpose of the requirements
determination step is to turn the very high-level explanation of the business
requirements stated in the system request into a more precise list of requirements
than can be used as inputs to the rest of analysis. This expansion of the requirements
ultimately leads to the design phase. 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, they are not merely computer
studies

REQUIREMENTS ANTICIPATION
Having had experience in a particular business area or having encountered systems in
an environment similar to the one currently under investigation will influence systems
analysts study. They may foresee the likelihood of certain problems or features and
requirements for a new system. As a result, the features they investigate for the
current 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 form
previous studies can lead to investigation of areas that would otherwise go unnoticed
by an inexperienced analyst. Having the background to know what to ask or which aspect
to investigate can be a substantial benefit to the organization.

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 of requirements anticipation.
REQUIREMENTS INVESTIGATION
This involves using a variety of tools and skills to study the current system and
document its features for further analysis. This relies heavily on fact-finding
techniques and includes methods for documenting and describing system features.

Investigate basic requirements: Analysts structure their investigation by seeking

answers to these four major questions:

What is the basic business Basic business process

process?
What data are used or Basic business input
produced during that and output.
process?

What are the limits imposed Basic business Scope &

by time and the volume of constraints
work?

What performance controls Basic business

are used? policies

Understand the Process: Begin with the basics. Analysts must raise questions
that, when answered, will provide a background of
fundamental details about the system and describe it.
Finding answers to the following questions will help
acquire the necessary understanding.

1. What is the purpose of Business purpose

this business activity?
2. What steps are Objectives
performed?
3. Where are they Scope
performed?
4. Who performs them? Roles & accessibility
5. How long does this take? Process Duration
6. How often is it done? Process Frequency
7. Who uses the resulting Users
information?

Suppose you are reinvestigating an inventory reordering system, something about which
you know very little. Where should you begin? Listed below are brief answers to basic
questions about the inventory reordering system. These are the kinds of answers you
would need to seek for any system you were studying

What is the purpose of To ensure that adequate quantities of stock and materials are
inventory reordering? on hand and available for use without carrying an excessive
and therefore costly quantity.

What steps are 1. Verifying stock on hand.

performed? 2. Determining future requirements and optimum times to
place orders.
3. Determining quantities to order.

Where are they The purchasing department, using information provided by

performed? manufacturing, sales, and inventory staff members, as well as
by its own records, handles ordering and lead – time.
Projection.

Who perform them? Purchasing manages approve all orders. Stock managers
assemble buying instructions and write orders.

How long does this The process may take a few minutes for simple and routine
take? high – prices item or other special circumstance.

How often is it done? This is a continuous process. Different items are always
being ordered.

Who uses the resulting Information produced as a by – product of this process is

information? used to manage inventory, schedule service and manufacturing
monitor purchasing, and pay suppliers, as well as meet
unexpected requirements for purchasing and inventory reorder
information.

Notice how quickly answers to these questions provide a broad understanding of what
inventory reordering is all about and show that the objective of inventory reordering
is more than just buying stock. But analysts cannot stop here. There is not yet enough
information to fully understand inventory reordering. Instead, the background acquired
enables to raise more detailed questions.

Identify data used and Analysts next need to find out what data are used to
information produced perform each activity for example, to reorder
inventory, the buyer might require data describing
the quantity of an item of hand, expected demand for
the item, supplier name, and item cost. To know when
to place an order, the buyer would also consider the
necessary lead-time (how far in advance the item
should be ordered to be on hand when needed).

Most business transactions also produce information

that is useful to managers when they evaluate
employee, business, and systems performance and that
may be useful in another context to both manager and
analyst. Inquiring analysts will find out, for
example that data about inventory reordering and
stocking also provide information about warehouse
demands, purchasing practices, sales, and cash flow.

Determine process timing and The frequency of business activities varies greatly.
volume For example, some activities, such as paying taxes,
occur only a few times a year, whereas paying
employees is a weekly activity. Therefore, analysts
should learn how often the activity is repeated.
Knowing whether an activity occurs frequently may
lead the analyst to raise many additional and
important questions to determine the reason for the
frequency and its effect on business activities.

Many times the easiest way to get this information is

to identify the reason for the activity: what causes
the activity to be performed? Analysts sometimes
refer to the direct cause as the trigger function.
(It triggers the activity.) Activities can be
triggered by customers of an application to open a
new bank, charge, or credit account), and by the
passage of time (the ending of the day, week, or
month). Unless analysts know what triggers an
activity, they may misunderstand the reason for the
activity and give it more or less importance in the
system than it merits.
 Some activities, such as completing a purchase
requisition, take only a few seconds. Others, such as
deciding whether to accept a merger offer, occur
infrequently but require a great deal of time when
they do take place. Timing alone does not determine
the importance of an activity, but it does affect the
way analysts evaluate certain steps in carrying out
the performance. For example, making a telephone call
to obtain stock price Information during a merger
decision is quite acceptable, since a merge is an
infrequent occurrence. But making a telephone call to
obtain information every time a purchase requisition
is processed is another matter.

The volume of items to be handled may increase the

amount of time needed to complete the activity.
Savings banks prepare consumer account statements
(summaries of deposits, withdrawals, interest
accumulations, and balances) only four times a year.
Although the frequency of this activity is very low,
when the calendar triggers this activity at the end
of each quarter, the volume of work is very high,
sometimes running into tens of thousands of
statements to be prepared. The sheer quantity of item
making up an activity can produce special problems
for the analyst to study, even though the activity
occurs infrequently

Identify controls In business situations that are well controlled

either by management or process monitoring,
determining whether an activity has been performed
properly may be no problem. But during the analysis
stage, the analysts must examine control methods:
Are there specific performance standards?
Who compares performance against standards?
How are mistakes caught?
How are error handled?
Are the errors excessive?

Weak or missing controls area is an important

discovery in any system investigation.
 User transaction Requirements
Transaction – level systems captures, process, and store data for a reason. In an
order system, for example, sale order form customers are processed so that specified
item can be shipped. This simple procedure applies to every order that is received.

Analysts assigned to work on an order entry system would want to know more about how
these transactions are processed. To understand these transaction requirements they
would undoubtedly ask questions such as the following:

1. What makes up the transaction being processed?

2. What initiates the transaction?
3. Who actually initiates the order? For what purpose?
4. How often do orders occur?
5. What volume is associated with each?
6. Are there different conditions that can affect how orders are processed?
7. What details are needed to process the transaction?
8. What information is generated? What data is stored?

BUSINESS SYSTEM IS REQUIREMENT INVESTIGATION

Executive management
TOP LEVEL Business Purpose DSS
Middle management and professional staff User decision Requirements
MIDDLE LEVEL Policies Goals and Objectives MIS
Supervisory staff

Clerical and service staff Basic business activities that fulfill purpose, goals, objectives & policies User transaction Requirements
LOWER TPS

User decision Requirements

Decision, unlike transaction activities, may not follow a specific procedure. Routines
are not as clear – cut, and controls may be very vague. Decisions are made by
integrating information in such a way that managers can know what actions to take.

Decision systems may focus on the past, the present, or the future. Some may support
recurring decisions (such as merchandise pricing, while others are unique and do not
recur). They may used data that originate inside the firm, such as through transaction
processing, or outside, for example form trade associations or commercial sources
(such as marketing research firms who sell information to organizations).

In some cases, transaction data are processed to provide new information for decision
making. For instance, summarized sales transaction data tell managers which products
sell and which do not.

Analysts investigating decision support systems should raise the same questions about
timing and frequency discussed previously. But other questions should also be posed to
determine decision requirements:

1. What information is used to make the Decision?

2. What is the source of the information? Which transaction system produce the
data used in the decision process?
3. Which data are required but do not result from processing transactions? Which
data originate from sources outside the organization?
4. How would data be processed to produce the necessary information?
5. How should the information be presented?

These questions also point out the relationship between transaction and decision
systems. If transaction systems do not capture and store the data needed for decision,
important information will be unavailable. Inventory systems capture details about
ongoing ordering, receipt, sale, and shipment of items, the data they store are
further processed to produce information periodically to analyze sales, determine
pricing policy, or decide on marketing plan for product lines.

This means:
1. That analysts investigating decision systems must be aware of supporting
transaction systems and
2. That effective decision systems require suitable transaction processing
procedures to be place first

Of course, this information rarely provides enough to build the system in question.
Usually the customer will later volunteer more demands (or change existing
ones) and provide clarifications to the gray areas when a developer needs it.

REQUIREMENT ELICITATION
The word “elicit” means to draw forth or bring out (something latent or potential)
Hence the need to actively engage stake holders in defining requirements. It is taken
for granted that users are ever willing to pour out a list of their requirement at the
slightest opportunity but in actual fact there is need in most cases to employ certain
methods that would ensure successful elicitation of requirements.

Elicitation is not an isolated activity but one that is required to be carried out
continuously throughout the requirement analysis and review cycle.

THE IMPORTANCE OF REQUIREMENT ELICITATION

Problems of scope The boundary of the system is ill-defined or the

customers/users specify unnecessary technical detail that
may confuse, rather than clarify, overall system
objectives.

Problems of The customers/users are not completely sure of what is

understanding needed, they have a poor understanding of the capabilities
and limitations of their computing environment, don’t have
a full understanding of the problem domain, have trouble
communicating needs to the system engineer, omit
information that is believed to be “obvious,” specify
requirements that conflict with the needs of other
customers/users, or specify requirements that are
ambiguous or untestable.

Problems of volatility The requirements change over time.

Problems of Error If a problem is identified and fixed at a later stage in

the software development process, it will cost much more
than if detected and fixed at an earlier stage. Since cost
is directly related with the success or failure of
projects, it is clear from all discussion that having
sound requirements is the most critical success factor for
any project

Problems of Input The requirement document serves as the base reference or

input document for the software development processes-
designing, coding, testing, delivery, management (for
monitoring and tracking) The diagram below depicts the
central role of software requirement document in the
entire development process.
Problems of Product Insufficient user involvement leads to unacceptable
Acceptability products If input from different types of user is not
taken, the output is bound to lack in key functional
areas, resulting in unacceptable products. Overlooking the
needs of certain user classes (Stakeholders) leads to
dissatisfaction of customers

Problems of Economy & Creeping user requirements contribute to overruns and

Quality degrade quality. Requirement creep is one of the most
significant factors in budget and time overruns. It is
basically means identifying and adding new requirements to
the list at some advanced stages of the software
development process.

Problems of Ambiguity Ambiguous requirements lead to ill-spent time and rework.

Ambiguity means that two different readers of the same
document interpret the requirement differently. Ambiguity
arises from the use of natural language. Because of the
imprecise nature of the language, different readers
interpret the statement differently.

Problems of Gold-Plating Gold-plating refers to features that are not present in

the original requirement document and in fact are not
important to the end-user but the developer adds them
anyway thinking that they would add value to the product.
Since these features are outside the initial scope of
the product, adding them will result in schedule and
budget overruns.

Problems of Completeness Minimal specifications lead to missing key requirements

and hence result in an unacceptable product. Incompletely
defined requirement make accurate project planning and
 tracking impossible.

REQUIREMENT ELICITATION TECHNIQUES

1. Brainstorming

Brainstorming works by focusing on a topic or problem, and then coming up with many
radical, haphazard or even absurd solutions to it. The suggested solutions are
documented, re-arranged reviewed afterwards. It is observed that new and excellent
discoveries would e made. It is a technique that promotes diversion type of thinking-
those team activities that produce a broad or diverse set of options. it is an
excellent way of elicitating many creative ideas for an area of interest. Structured
brainstorming produces numerous ideas about any given "central question" or "topic".
It is best applied as a group as it draws on the experience and creativity of all
members of the group, one could brainstorm on one's own to spark new ideas.

2. Document Analysis

This is a means of requirement elicitation that involves the studying of available

documentation and identifying relevant information. Document analysis is used if the
objective is to gather details of the existing system such as business rules,
entities, and attribute that need be included in a new system or need to be updated
for the current system. This technique would be applicable in situations where the
subject matter experts for the existing systems are not available during the
elicitation process.

Project teams often use document analysis to understand the as-is system. Under ideal
circumstances, the project team that developed the existing system will have produced
documentation, which was then updated by all subsequent projects. In this case, the
project team can start by reviewing the documentation and examining the system itself.

Unfortunately, most systems are not well documented because project teams fail to
document their projects along the way, and when the projects are over—there is no time
to go back and document. Therefore, there may not be much technical documentation
about the current systems available, or it may not contain updated information about
recent system changes. However, there are many helpful documents that do exist in the
organization: paper reports, memorandums, policy manuals, user training manuals,
organization charts, and forms
Documents (forms, reports, policy manuals, organization charts) only tell part of the
story. They represent the formal system that the organization uses. Quite often, the
“real” or informal system differs from the formal one, and these differences,
particularly large ones, give strong indications of what needs to be changed. For
example, forms or reports that are never used likely should be eliminated. Likewise,
boxes or questions on forms that are never filled in (or are used for other purposes)
should be rethought

The most powerful indication that the system needs to be changed is when users create
their own forms or add additional information to existing ones. Such changes clearly
demonstrate the need for improvements to existing systems. Thus, it is useful to
review both blank and completed forms to identify these deviations. Likewise, when
users access multiple reports to satisfy their information needs, it is a clear sign
that new information or new information formats are needed.

Many kinds of documents and reports can provide analysts with valuable information
about organizations and operations. In document reviews, analysts examine information
that has been recorded about the system and user. Document inspection can be performed
at the beginning of the study, as an introduction, or later in the study, as a basis
for comparing; actual operations with the records indicate should be happening.

Documents or Records include written policy manuals, regulations and standard

operating procedures used by most organizations and a guide for managers and
employees. They do not show what activities are actually occurring, where the decision
– making power lies, or how tasks are performed. However, they can help analysts
understand the system by familiarizing them with what operations must be supported and
with formal relations within the organization.
Form marked to indicate data elements
3. Interview

An interview is a systematic approach to elicit information from a person or group of

people in an informal or formal setting by talking to the person - interviewee, asking
relevant questions and documenting the responses.

In an interview the analyst formally or informally directs the questions to a

stakeholder, a subject-matter-expert or a potential user to obtain answers that
finally take the shape of requirements. One-on-one interviews are typically most
common. In a group interview the interviewer must be careful to solicit responses
from all attendees.

Sample Questions:

TYPE 1: Context-Free questions: a set of questions that will lead to a basic

understanding of the problem
 Identify stakeholders who will have interest in the software to be
built.
 Identify the measurable benefit of a successful implementation
 Identify possible alternatives to custom software development

e.g.
o Who is behind the request for this work?
o Who will use the solution?
o What will be the economic benefit of a successful solution?
o Is there another source for the solution that you need?

TYPE 2: A set of questions enables the analyst to gain a better understanding of

the problem and the customer to voice his or her perceptions about a
solution
 Functional requirement questions
 Non-Functional requirement questions
 Usability questions
 Interface questions
e.g
o What are the ways to accomplish this goal?
o Tell me about your frustration with this process?
o What problem(s) will this solution address?
o What makes a good day?
o What standards or regulations should we be aware of?
 o What purpose is accomplished by using the product?
o How long should a task take?
o Will special performance issues or constraints affect the
way the solution is approached?
o How do you define success?
o How would you characterize "good" output that would be
generated by a successful solution?
o What people do you share information with?
o what information is passed to other systems?
o Can you show me (or describe) the environment in which the
solution will be used?
TYPE 3: Meta-Questions-A set of questions that focus on the effectiveness of the
meeting.
e.g

o Am I asking too many questions?

o Are my questions relevant to the problem that you have?
o Can anyone else provide additional information?
o What didn't I ask that i should have?
o Are you the right person to answer these questions? Are
your answers "official?
o Was this interview effective?
o If we could change one thing about the process, what should
it be?
A question and answer meeting format is not an approach that has been overwhelmingly
successful. In fact, the Q&A session should be used for the first encounter only and
then replaced by a meeting format that combines elements of problem solving,
negotiation, and specification as done in focus groups.

Selecting Interviewees
1. Create an interview schedule that lists all of the people who will be interviewed,
when, and for what purpose (
2. The people who appear on the interview schedule are selected based on the analyst’s

information needs. People at different levels of the organization will have

different perspectives on the system, so it is important to include both managers
who manage the processes and staff who actually perform the processes to gain both
high-level and low-level perspectives on an issue.

3. The project sponsor, key business users, and other members of the project team can
help the analyst determine who in the organization can best provide important
information about requirements. These people are listed on the interview schedule
in the order in which they should be interviewed.

4. It is common to begin by interviewing one or two senior managers to get a strategic

view, and then move to mid-level managers who can provide broad, over-arching
information about the business process and the expected role of the system being
developed.

5. Once the analyst has a good understanding of the “big picture,” lower-level
managers and staff members can fill in the exact details of how the process works.
Like most other things about systems analysis, this is an iterative process—
starting with senior managers, moving to mid-level managers, then staff members,
back to mid-level man-agers, and so on, depending upon what information is needed
along the way

Designing Interview Questions

There are three types of interview questions:

1. Closed-ended questions
2. Open-ended questions
3. Probing questions
Closed-ended questions Closed-ended questions are those that require a specific
answer. You can think of them as being similar to multiple
choice or arithmetic questions on an exam.

Closed-ended questions are used when the analyst is looking

for specific, precise information (e.g., how many credit
card requests are received per day). In general, precise
questions are best. For example, rather than asking “Do you
handle a lot of requests?” it is better to ask “How many
requests do you process per day?

Closed-ended questions enable analysts to control the

interview and obtain the information they need. However,
these types of questions don’t uncover why the answer is
the way it is, nor do they uncover information that the
interviewer does not think to ask ahead of time.

Open-ended questions Open-ended questions are those that leave room for
elaboration on the part of the interviewee. They are
similar in many ways to essay questions that you might find
on an exam.

Open-ended questions are designed to gather rich

information and give the interviewee more control over the
information that is revealed during the interview.
Sometimes the information that the interviewee chooses to
discuss uncovers information that is just as important as
the answer (e.g., if the interviewee talks only about other
departments when asked for problems, it may suggest that he
or she is reluctant to admit his or her own problems).

Probing question Probing questions follow-up on what has just been discussed
in order to learn more, and they often are used when the
interviewer is unclear about an interviewee’s answer. They
encourage the interviewee to expand on or to confirm
information from a previous response, and they are a signal
that the interviewer is listening and interested in the
topic under discussion.

Many beginning analysts are reluctant to use probing

questions because they are afraid that the interviewee
 might be offended at being challenged or because they
believe it shows that they didn’t understand what the
interviewee said. When done politely, probing questions can
be a powerful tool in requirements gathering.

In general, do not ask questions about information that is

readily available from other sources. For example, rather
than asking what information is used to perform a task, it
is simpler to show the interviewee a form or report (see
document analysis) and ask what information on it is used.
This helps focus the interviewee on the task, and saves
time, because he or she does not need to describe the
information detail—he or she just needs to point it out on
the form or report.

Choosing the interview type

Unstructured interviews: interviews that seek a broad and roughly defined set of
information. In this case, the interviewer has a general
sense of the information needed, but few close-ended
questions to ask. These are the most challenging interviews
to conduct because they require the interviewer to ask
open-ended questions and probe for important information as
the need arises.

Structured interviews: specific sets of questions are developed prior to the

interviews. There usually are more close-ended questions in
a structured interview than in the unstructured approach.

No question type is better than another, and usually a combination of questions is

used during an interview. At the initial stage of an IS development project, the as-is
process can be unclear, so the interview process begins with unstructured interviews.
As the project progresses, the analyst comes to understand the business process much
better, and he or she needs very specific information about how business processes are
per-formed (e.g., exactly how a customer credit card is approved). At this time, the
analyst con-ducts structured interviews.

No matter what kind of interview is being conducted, interview questions must be

organized into a logical sequence, so that the interview flows well. For example, when
trying to gather information about the current business process, it can be useful to
move in logical order through the process or from the most important issues to the
least important.

Choosing the interview strategy

There are two fundamental approaches to organizing the interview questions:
1. Top-down
2. bottom-up

Top-down with the top-down interview, the interviewer starts with broad,
general issues and gradually works towards more specific ones. The
top-down approach is an appropriate strategy for most interviews
(it is certainly the most common approach). The top-down approach
enables the interviewee to become accustomed to the topic before
he or she needs to provide specifics. It also enables the inter-
viewer to understand the issues before moving to the details
because the interviewer may not have sufficient information at the
start of the interview to ask very specific questions. Perhaps
most importantly, the top-down approach enables the interviewee to
raise a set of “big picture” issues before becoming enmeshed in
details, so the interviewer is less likely to miss important
issues.
Bottom-up with the bottom-up interview, the interviewer starts with very
specific questions and moves to broad questions. One case in which
the bottom-up strategy may be preferred is when the analyst
already has gathered a lot of information about issues and just
needs to fill in some holes with details. Or, bottom-up may be
appropriate if lower-level staff members are threatened or unable
to answer high-level questions. For example, “How can we improve
customer service?” may be too broad a question for a customer
service clerk, whereas a specific question is readily answerable
(e.g., “How can we speed up customer returns?”).

In any event, all interviews should begin with noncontroversial questions first, and
then gradually move into more contentious issues after the interviewer has developed
some rapport with the interviewee.

Preparing for the Interview

1. Have a general interview plan that lists the questions that you will ask in the
appropriate order; anticipates possible answers and provides how you will
follow up with them; and identifies segues between related topics

2. Confirm the areas in which the interviewee has knowledge so you do not ask
questions that he or she cannot answer.

3. Review the topic areas, the questions, and the interview plan, and clearly
decide which have the greatest priority in case you run out of time.

4. In general, structured interviews with closed-ended questions take more time to

pre-pare than unstructured interviews. So, some beginning analysts prefer
 unstructured interviews, thinking that they can “wing it.” This is very
dangerous and often counterproductive, because any information not gathered in
the first interview would require follow-up efforts, and most users do not like
to be interviewed repeatedly about the same issues

5. Prepare the interviewee as well. When you schedule the interview, inform the
interviewee of the reason for the interview and the areas you will be
discussing far enough in advance so that he or she has time to think about the
issues and organize his or her thoughts.

Conducting the Interview

1. Build rapport with the interviewee, so that he or she trusts you and is willing
to tell you the whole truth, not just give the answers that he or she thinks
you want.

2. Be professional and an unbiased, independent seeker of information.

3. The interview should start with an explanation of why you are there and why you
have chosen to interview the person, and then move into your planned interview
questions.

4. Carefully record all the information that the interviewee provides. Recording
ensures that you do not miss important points, but it can be intimidating for
the interviewee. Most organizations have policies or generally accepted
practices about the recording of interviews, so find out what they are before
you start an interview. If you are worried about missing information and cannot
tape the interview, then bring along a second person to take detailed notes.

5. As the interview progresses, it is important that you understand the issues

that are discussed. If you do not understand something, be sure to ask. Don’t
be afraid to ask “dumb questions” because the only thing worse than appearing
“dumb” is to be “dumb” by not understanding something.

6. Periodically summarize the key points that the interviewee is communicating.

This avoids misunderstandings and also demonstrates that you are listening.

7. Separate facts from opinion. The interviewee may say, for example, “we process
too many credit card requests.” This is an opinion, and it is useful to follow
this up with a probing question requesting support for the statement (e.g.,
“Oh, how many do you process in a day?”). It is helpful to check the facts
 because any differences between the facts and the interviewee’s opinions can
point out key areas for improvement.

8. As the interview draws to a close, be sure to give the interviewee time to ask
questions or provide information that he or she thinks is important but was not
part of your interview plan

9. Make sure that the interview ends on time (if necessary, omit some topics or
plan to schedule another interview).

10. As a last step in the interview, briefly explain what will happen next to
reassure the interviewee that his or her time was well spent and very helpful
to the project.

Post-Interview Follow-up

1. After the interview is over, the analyst needs to prepare an interview report
that describes the information from the interview. The report contains
interview notes, information that was collected over the course of the
interview and is summarized in a useful format.

2. In general, the interview report should be written within forty-eight hours of

the interview, because the longer you wait, the more likely you are to forget
information.

3. Often, the interview report is sent to the interviewee with a request to read
it and inform the analyst of clarifications or updates. Make sure the
interviewee is convinced that you genuinely want his or her corrections to the
report

4. Usually there are few changes, but the need for any significant changes
suggests that a second interview will be required. Never distribute someone’s
information without prior approval
6. Focus Groups

A focus group is a means to elicit ideas and attitudes about a specific product,
service or opportunity in an interactive group environment. The Participants share
their impressions, preferences and needs, guided by a moderator.

7. Observation

This is a means to elicit requirements by conducting an assessment of the subject

matter expert's work environment. It is the act of watching processes being performed,
is a powerful tool for gathering information about the as-is system because it enables
the analyst to see the reality of a situation, rather than listening to others
describe it in interviews or JAD sessions.

The goal is to keep a low profile, to not interrupt those working, and to not
influence those being observed. Nonetheless, it is important to understand that what
analysts observe may not be the normal day-to-day routine because people tend to be
extremely careful in their behavior when they are being watched. Even though normal
practice may be to break formal organizational rules, the observer is unlikely to see
this. Thus, what you see may not be what you get.

Observation is often used to supplement interview information. The location of a

person’s office and its furnishings gives clues as to their power and influence in the
organization, and can be used to support or refute information given in an interview.
For example, an analyst might become skeptical of someone who claims to use the
existing computer system extensively if the computer is never turned on while the
analyst visits.

In most cases, observation will support the information that users provide in
interviews. When it does not, it is an important signal that extra care must be taken
in analyzing the business system.

This technique is appropriate when documenting details about the current processes or
if the project intends to enhance or change current processes.

2 basic approaches:

Passive/invisible: In this approach, the business analyst observes the subject

matter expert working through the business routine but does
not ask questions. The analyst writes notes about what
he/she sees, but otherwise stays out of the way, as if
he/she was invisible. The analyst waits until the entire
process has been completed before asking questions.
The analyst observes the business process multiple times
before he/she understands how the process works today and
why it works the way it does.

Active/Visible: Here while the analyst observes the current process and
takes notes he/she may dialog with the worker. The analyst
can ask questions right away even if it breaks the routine
of the person being observed. The analyst might even
participate in the work to gain an immediate appreciation
of how the current system works.

8. Prototyping

When prototyping is used as an elicitation technique, it aims to uncover and visualize

interface requirements before the application is designed or developed.

2 categories exist:
Functional Scope: A horizontal prototype models a shallow and wide view of the
system functionality while the vertical prototype models a deep
but a narrow view of the system functionality.

SDLC usage: A "Throw-away" prototype seeks to quickly uncover and clarify

requirements using simple tools, sometimes using just pen and
paper. Such prototype is usually discarded when the final system
has been developed. An "Evolutionary or functional " prototype
extends the initial interface requirement into the fully
functioning system and requires a specialized prototyping tool or
language.

9. Requirement Workshop:

This is a highly productive focused event attended by carefully selected stakeholders

and subject matter experts for a short, intensive period; typically a few days. It is
a structured way to capture requirements. It may be used to scope, discover define,
prioritize and reach closure on requirements for the target system. Well-run workshops
are considered one of the most effective ways to deliver high quality requirements
quickly. They promote trust, Mutual understanding, and strong communications among the
project stakeholders and project team and produce deliverables that structure and
guide future analysis

10. Survey/Questionnaire

A questionnaire/survey is a set of written questions for obtaining information from

individuals. Questionnaire/survey often is used when there are a large number of
people from whom information and opinions are needed. It is a means of elicitating
information from many people anonymously, in a short time. A questionnaire/survey can
collect information about customers, products, work practices and attitudes; a survey
is often referred to as a questionnaire. A survey administers a set of written
questions to the stakeholders and subject matter experts. Their responses are analyzed
and distributed to the appropriate parties.

Selecting Participants:
1. Select the individuals to whom the questionnaire will be sent. The standard
approach is to select a sample, or subset, of people who are representative of the
entire group
2. Not everyone who receives a questionnaire will actually complete it. On aver-age,
only 30 to 50 percent of paper and e-mail questionnaires are returned. Response
rates for Web-based questionnaires tend to be significantly lower (often only 5 to
30 percent).

Designing the Questionnaire

1. Developing good questions is critical for questionnaires because the

information on a questionnaire cannot be immediately clarified for a confused
respondent.

2. Questions on questionnaires must be very clearly written and leave little room
for misunderstanding, so closed-ended questions tend to be most commonly used

3. Questions must clearly enable the analyst to separate facts from opinions.
Opinion questions often ask the respondent the extent to which they agree or
disagree (e.g., “Are network problems common?”), while factual questions seek
more precise values (e.g., “How often does a network problem occur: once an
hour, once a day, once a week?”)

4. Have a clear understanding of how the information collected from the

questionnaire will be analyzed and used.

5. Questions should be relatively consistent in style, so that the respondent does

not have to read instructions for each question before answering it.

6. Group related questions together to make them simpler to answer

7. Questionnaires should start with questions important to respondents, so that

the questionnaire immediately grabs their interest and induces them to answer
it.

8. Have several colleagues review the questionnaire and then pretest it with a few
people drawn from the groups to whom it will be sent.

9. Begin with nonthreatening and interesting questions.

10. Group items into logically coherent sections.
11. Do not put important items at the very end of the questionnaire.
 12. Do not crowd a page with too many items.
13. Avoid abbreviations.
14. Avoid biased or suggestive items or terms.
15. Number questions to avoid confusion.
16. Pretest the questionnaire to identify confusing questions.
17. Provide anonymity to respondents.

Administering the questionnaire

1. The key issue in administering the questionnaire is get-ting participants to

complete the questionnaire and send it back

2. clearly explain why the questionnaire is being conducted and why the respondent
has been selected; stating a date by which the questionnaire is to be returned;
offering an inducement to complete the questionnaire (e.g., a free pen); and
offering to supply a summary of the questionnaire responses.

3. Personally hand out the questionnaire and personally contacting those who have
not returned them after a week or two, as well as requesting the respondents’
supervisors to administer the questionnaires in a group meeting.

Questionnaire Follow-up

It is helpful to process the returned questionnaires and develop a questionnaire

report soon after the questionnaire deadline. This ensures that the analysis process
proceeds in a timely fashion and that respondents who requested copies of the results
receive them promptly.

Implementing group meetings: Focus Groups and Requirement Workshop

The facilitator: The facilitator is a person who sets the meeting agenda and
guides the discussion, but does not join in the discussion
as a participant. He or she does not provide ideas or
opinions on the topics under discussion to remain neutral
during the session.
 The facilitator must be an expert in both group process
techniques and systems analysis and design techniques.

Scribes: One or two scribes assist the facilitator by recording

notes, making copies, and so on. Often the scribes will use
computers and CASE tools to record information as the JAD
session proceeds.

The meeting room: The meeting room is usually arranged in a U shape so that
all participants can easily see each other. At the front of
the room (the open part of the “U”), there is a whiteboard,
flip chart and/or overhead projector for use by the
facilitator who leads the discussion. In an e-meeting room,
each participant uses special software on a networked
computer to send anonymous ideas and opinions to everyone
else. In this way, all participants can contribute at the
same time, without fear of reprisal from people with
differing opinions.

Frequency of meeting: The group meets for several hours, several days, or several
weeks until all of the issues have been discussed and the
needed information is collected.

Selecting Participants
 1. Participants are selected based on the information they can con-tribute, to
provide a broad mix of organizational levels, and to build political support
for the new system.

2. The facilitator should be someone who is an expert in the business under

discussion. In many cases, the facilitator is a consultant external to the
organization because the organization may not have a regular day-to-day need
for the expertise. Developing and maintaining this expertise in-house can be
expensive

Designing the Session:

1. Sessions can run from as little as a half day to several weeks, depending upon
the size and scope of the project. Meeting sessions are structured—they must
be carefully planned. In general, closed-ended questions are seldom used
because they do not spark the open and frank discussions. In our experience, it
is better to proceed top-down in the sessions when gathering information.

2. Typically thirty minutes is allocated to each separate agenda item, and

frequent breaks are scheduled throughout the day because participants tire
easily

Preparing for the Session

Prepare the analysts and participants for the JAD session. Because the sessions can go
beyond the depth of a typical interview and are usually conducted off-site,
participants can be more concerned about how to prepare. It is important that the
participants understand what is expected of them.

Conducting the Session

 Follow a formal agenda, and most have formal ground rules that define
appropriate behavior

 Common ground rules include following the schedule, respecting others,

opinions, accepting disagreement, and ensuring that only one person talks a
time.

 Ensures that the group sticks to the agenda.

  Facilitator must help the group understand the technical terms and jargon that
surround the system development process, and help the participants under-stand
the specific analysis techniques used. Participants are experts in their area,
their part of the business, but they are not experts in systems analysis. The
facilitator must therefore minimize the learning required and teach
participants how to effectively pro-vide the right information

 The facilitator records the group’s input on a public display area, which can
be a whiteboard, flip chart, or computer display. He or she structures the
information that the group provides and helps the group recognize key issues
and important solutions. Under no circumstance should the facilitator insert

his or her opinions into the discussion. However, this does not mean that the
facilitator should not try to help the group resolve issues.

Post session Follow-up

A possession report is prepared and circulated among session attendees. The post-
session report is essentially the same as the interview report. Since the JAD sessions
are longer and provide more information,

Selecting the Appropriate Techniques

Each of the requirements-gathering techniques just discussed has strengths and weak-
nesses. No one technique is always better than the others, and in practice most
projects use a combination of techniques. Thus, it is important to understand the
strengths and weaknesses of each technique and when to use each
REQUIREMENTS GATHERING
A single requirement is, basically, a constraint on the system being developed. Each
of these constraints typically addresses a single specific aspect of the
system and can be positive ("the system must do X"), negative ("the system
must not do X") or some shade in between ("It would be nice for the system to do X,
but we can live without it just as well").

The preparation for requirement gathering largely depends on what tools are
being used for requirement modeling. The most important part of this
preparation is capturing and categorizing all information provided by the
customer in its raw form - this is what requirement modeling will work with.

In the scope of our approach we use the term project document library to refer to a
collection of raw information provided by the customer for the specific
project. The individual documents in this library are project visions,
relevant standards, customer interview logs, etc. The main idea here is that
a project document library will contain all raw information relevant for the
project and nothing else.

The process of gathering raw requirements basically involves going through the project
document library, finding such constraints and creating a separate requirement
for each constraint found. At this point we do not care about things like classifying
these requirements or whether they conflict with each other. All we need to do is
to collect the requirements and tag each one with the importance / urgency
(Must, Should, Could, Must not, etc.).

As the requirement modeling diagram suggests, the process of gathering raw

requirements is not usually performed in one go. Each time customer provides
more information (either voluntary or answering a request from a requirement
modeler or developer) this new information must be scanned for additional
requirements.

GUIDELINES FOR REQUIREMENT GATHERING

To help overcome the above problems, the approach of requirements gathering activity
must be organized.

1. Define Project Scope

Project scope defines the concept and range of the proposed solution, and limitations
identifying certain capabilities that the product will not include. Guard against
scope creep by tracing requirements back to the project goals/objectives and Assessing
the business and technical feasibility for the proposed system. This helps to validate
whether a requirement should be included.

2. Prioritize requirements

It is usually helpful to separate requirements into 3 categories:

a. Requirements that absolutely must be met

b. Requirements that is highly desirable but not necessary

c. Requirements that are possible but could be eliminated

Documenting requirements attributes such as the requirement source, value and priority
will aid managing each requirement throughout its life cycle.

3. Define the environment

Define the technical environment (e.g., computing architecture, operating system,

telecommunications needs) into which the system or product will be placed.

4. Identify constraints

Identify “domain constraints” (i.e., characteristics of the business environment

specific to the application domain) that limit the functionality or performance of the
system or product to be built
5. Define the elicitation method

Define one or more requirements elicitation methods (e.g., interviews, focus groups,
team meetings)

6. Identify the stakeholders

Identify the people who will help specify requirements and understand their
Organizational bias. It is important to solicit participation from many people so that
requirements are defined from different points of view; be sure to identify the
rationale for each requirement that is recorded. Create usage scenarios to help
customers/users better identify key requirements

7. Identify ambiguity

Identify ambiguous requirements as candidates for prototyping.

8. Track Elicitation Participation

Tracking elicitation participation and the actual time spent eliciting the
requirements provides a basis for future planning.

REQUIREMENT ANALYSIS
1. Discovery

2. Classification and organization

3. Prioritization and negotiation

REQUIREMENT DISCOVERY
Requirements discovery is the process of distilling user and system requirements from
gathered information about the required system and existing systems.

Different viewpoints on a problem see the problem in different ways. However,

perspectives are not completely independent but usually overlap so that they have
common requirements. These viewpoints can be used to structure the discovery.

Requirements are not independent of each other. It is up to the requirement modeler

to decide what associations between requirements are relevant and shall be tracked.
Specific examples of such associations include:

Dependency: if a requirement A depends upon the requirement

B, then it is impossible to implement A
without implementing B first. The information about
requirement dependency is important for both change
impact analysis and deciding what requirements to
include in a specific requirement baseline.

Conflict: it is not uncommon for the customer to make

contradictory demands, especially when these demands
come from more than one source. When these demands
become requirements, it is essential that the
information about their incompatibility be captured.
Conflicting requirements can never be implemented in
the same system and, as a result, always require
clarification from the customer.

Equivalence: two equivalent requirements describe the same

constraint on the system in different terms.
Clearly, only one of these should be retained so,
again, a clarification from the customer is
needed.

Correlation: it is often the case that a number of requirements

must be treated as a group, i.e. if one of these
requirements makes it into the release, then
the entire group must do the same. For
example, when a composite requirement is split
into simple requirements, the resulting simple
requirements are correlated, because, to the
customer, they are still one requirement (the
 original composite one; decomposition is just a way
to make life easier for the developer)

Requirements discovery techniques

Interviewing
Scenarios
Use cases
Ethnography

Interviewing
Formal or informal interviews with system stakeholders are part of most requirements
engineering processes. In these interviews, the requirements engineering team puts
questions to stakeholders about the system that they currently use and the sys-tem to
be developed. Requirements are derived from the answers to these questions.

Interviews may be of two types:

1. Closed interviews, where the stakeholder answers a pre-defined set of

questions.
2. Open interviews, in which there is no pre-defined agenda. The requirements
engineering team explores a range of issues with system stakeholders and hence
develops a better understanding of their needs.

In practice, interviews with stakeholders are normally a mixture of both of these.

Completely open-ended discussions rarely work well. There is a need to ask some
questions to get started and to keep the interview focused on the system to be
developed.

Merits

Interviews are good for:

 Getting an overall understanding of what stakeholders do

 How they might interact with the new system
 Knowing the difficulties that they face with current systems

People like talking about their work so are usually happy to get involved in
interviews.

Demerits:
1. However, interviews are not so helpful in understanding the requirements from the
application domain. It can be difficult to elicit domain knowledge through
interviews for two reasons:

(1) All application specialists use terminology and jargon that are specific
to a domain. It is impossible for them to discuss domain requirements
without using this terminology. They normally use terminology in a
precise and subtle way that is easy for requirements engineers to
misunderstand.

(2) Some domain knowledge is so familiar to stakeholders that they either

find it difficult to explain or they think it is so fundamental that it
isn’t worth mentioning. For example, for a librarian, it goes without
saying that all acquisitions are catalogued before they are added to the
library. However, this may not be obvious to the interviewer, and so it
isn’t taken into account in the requirements.

2. Interviews are also not an effective technique for eliciting knowledge about
organizational requirements and constraints because there are subtle power
relationships between the different people in the organization. Published
organizational structures rarely match the reality of decision making in an
organization but interviewees may not wish to reveal the actual rather than the
theoretical structure to a stranger. In general, most people are generally
reluctant to discuss political and organizational issues that may affect the
requirements.

Effective interviewers have two characteristics:

1. They are open-minded, avoid pre-conceived ideas about the requirements,

and are willing to listen to stakeholders. If the stakeholder comes up
with surprising requirements, then they are willing to change their mind
about the system.

2. They prompt the interviewee to get discussions going using a springboard

question, a requirements proposal, or by working together on a prototype
system. Saying to people ‘tell me what you want’ is unlikely to result in
useful information. They find it much easier to talk in a defined context
rather than in general terms.
Information from interviews supplements other information about the system from
documentation describing business processes or existing systems, user observations,
etc. Sometimes, apart from the information in the system documents, the interview
information may be the only source of information about the system requirements.
However, interviewing on its own is liable to miss essential information and so it
should be used in conjunction with other requirements elicitation techniques.

Scenarios
Scenarios are real-life examples rather than abstract descriptions of interactions.
People usually find it easier to relate to real-life examples rather than
abstract descriptions. They can understand and criticize a scenario of how they might
interact with a software system. Requirements engineers can use the information gained
from this discussion to formulate the actual system requirements.

Scenarios can be particularly useful for adding or discovering the detail to an

outline requirements description. They are descriptions of example interaction
sessions

Each scenario usually covers one or a small number of possible interactions. Different
forms of scenarios are developed and they provide different types of information at
different levels of detail about the system. The stories used in extreme programming
are a type of requirements scenario.

A scenario starts with an outline of the interaction. During the elicitation process,
details are added to this to create a complete description of that interaction. At its
most general, a scenario may include:

1. A description of what the system and users expects when the scenario starts.
2. A description of the normal flow of events in the scenario.
3. A description of what can go wrong and how this is handled.
4. Information about other activities that might be going on at the same time.
5. A description of the system state when the scenario finishes

Scenario-based elicitation involves working with stakeholders to identify scenarios

and to capture or discover details to be included in these scenarios. Scenarios may be
written as text, supplemented by diagrams, screen shots, etc. Alternatively, a more
structured approach such as event scenarios or use cases may be used.

Use cases
Use cases are a requirements discovery technique that were first introduced in the

Object orientation methodologies. Use cases identify the individual interactions

between the system and its users or other systems. A use case identifies the actors
involved in an interaction and names the type of interaction. The set of use cases
represents all of the possible interactions that will be described in the system
requirements. This is then supplemented by additional information describing the
interaction with the system

Use cases are documented using a high-level use case diagram. Actors in the process,
who may be human or other systems, are represented as stick figures. Each class of
interaction is represented as a named ellipse. Lines link the actors with the
interaction. Optionally, arrowheads may be added to lines to show how the interaction
is initiated.

There is no hard and fast distinction between scenarios and use cases. Some people

consider that each use case is a single scenario; others encapsulate a set of scenarios
in a single use case. Each scenario is a single thread through the use case.
Therefore, there would be a scenario for the normal interaction plus scenarios for
each possible exception. Each use case should be documented with a textual
description.

Scenarios and use cases are effective techniques for eliciting requirements from
stakeholders who interact directly with the system. Each type of interaction can be
represented as a use case. However, because they focus on interactions with the
system, they are not as effective for eliciting constraints or high-level business and
non-functional requirements or for discovering domain requirements.
The UML is a de facto standard for object-oriented modeling, so use cases and use
case–based elicitation are now widely used for object oriented requirements
elicitation.

Ethnography
Systems do not exist in isolation. They are used in a social and organizational
context and system requirements may be derived or constrained by that context.
Satisfying these social and organizational requirements is often critical for the
success of the system.

One reason why many systems are delivered but never used is that their requirements do
not take proper account of how the social and organizational context affects the
practical operation of the system.

Ethnography is an observational technique that can be used to understand operational

processes and help derive support requirements for these processes. An analyst
immerses himself or herself in the working environment where the system will be used.
The day-to-day work is observed and notes made of the actual tasks in which
participants are involved. The value of ethnography is that it helps discover implicit
system requirements that reflect the actual ways that people work, rather than the
formal processes defined by the organization.

People often find it very difficult to articulate details of their work because it is
second nature to them. They understand their own work but may not understand its
relationship to other work in the organization. Social and organizational factors that
affect the work, but which are not obvious to individuals, may only become clear when
noticed by an unbiased observer.

Ethnography is particularly effective for discovering two types of requirements:

1. Requirements that are derived from the way in which people actually work,
rather than the way in which process definitions say they ought to work. For
example, air traffic controllers may switch off a conflict alert
system that detects aircraft with intersecting flight paths, even
though normal control procedures specify that it should be used. They
deliberately put the aircraft on conflicting paths for a short time to help
manage the airspace. Their control strategy is designed to ensure that these
aircrafts are moved apart before problems occur and they find that the
conflict alert alarm distracts them from their work.
 2. Requirements that are derived from cooperation and awareness of other people’s
activities. For example, air traffic controllers may use an awareness of other
controllers’ work to predict the number of aircrafts that will be entering
their control sector. They then modify their control strategies depending on
that predicted workload. Therefore, an automated ATC system should allow
controllers in a sector to have some visibility of the work in adjacent
sectors.

Ethnography can be combined with prototyping. The ethnography informs the development
of the prototype so that fewer prototype refinement cycles are required. Furthermore,
the prototyping focuses the ethnography by identifying problems and questions that can
then be discussed with the ethnographer

Ethnographic studies can reveal critical process details that are often missed by
other requirements elicitation techniques. However, because of its focus on the end-
user, this approach is not always appropriate for discovering organizational or domain
requirements. They cannot always identify new features that should be added to a
system. Ethnography is not, therefore, a complete approach to elicitation on its own
and it should be used to complement other approaches, such as use case analysis.

REQUIREMENT CLASSIFICATION AND ORGANIZATION