P. 1
Systems Analysis and Design 2nd Edition_Opt

Systems Analysis and Design 2nd Edition_Opt

|Views: 108|Likes:
Published by Ranz Adamson

More info:

Published by: Ranz Adamson on Nov 30, 2010
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Requirements engineering is a term used to describe activities that, at first
sight, closely resemble systems analysis and design. The techniques used in
requirements engineering are the same techniques that we describe as part
of systems analysis. Systems models using structured analysis and object-
oriented analysis can all be used by the requirements engineer. However, the
perspective of the requirements engineer is different from that of the systems
analyst. Requirements engineering is a fundamental aspect of business analysis,
and it is significant that the ISEB Diploma in Business System Development
that specialises in business analysis identifies requirements engineering as one
of its core components.
This emphasis on the requirements phase of the life cycle comes from an in-
creasing awareness in organisations involved in the development of computer-
based systems that the poor performance, late delivery and high maintenance
cost of software systems come from a failure to understand and specify require-
ments at the outset of the project. The use of the term ‘to engineer’ adds weight
to the view that sees this stage of the life cycle as a formalised and structured
activity that underpins the quality of the design.
Requirements engineering is frequently used when the development is of a
technical or scientific nature rather than a business-based system. The business-
based system often derives its characteristics from the behaviour of the system’s
users, and the systems analyst is always aware of the importance of the user’s
acceptance of the way in which the new system will operate. Systems that are
developed for technical purposes, such as missile control systems, air traffic
control systems or aircraft control systems, must still originate from a set of
requirements, but these requirements will be based upon mechanical and phys-
ical characteristics rather than human and organisational ones. Recognising the
need to apply a structured, documented approach to the identification and defi-
nition of these requirements is an important step towards the establishment of
professional standards for the software engineer engaged in these developments.
The same standards encourage the business analyst to apply an engineering per-
spective when developing a business system solution that will accommodate the
changing patterns of the commercial world.
The life cycle for requirements engineering closely resembles that used by the
systems analyst, although the emphasis is on establishing high-level definitions
of requirements that provide an overall design, which can then be decomposed
into lower-level, more detailed requirements. The system partition is done by re-
quirements, and this can be contrasted with the process partition that is used in
structured systems analysis and the object partition that is used in OO analysis
and design. The requirements engineer would argue, quite reasonably, that
requirements engineering postpones the selection of a development method,
and this avoids the creation of a solution that is dictated by the methodology that
defines it.

The process of establishing requirements is subdivided into three stages:
elicitation, analysis and validation. Requirements elicitation is the investi-
gation stage of this process, and the requirements engineer will use the

interview, observation and modelling techniques in the same way as the systems
analyst. The identification of stakeholders and their classification is an important
element in this process. The CATWOE principle described earlier is adapted to
allow the engineer to recognise the different perspectives of those who sponsor
the system by paying for its development; those who own the system and who
will be responsible for its ongoing use and development; those who monitor the
quality and the system’s conformance to organisational standards; and finally
those who have an influence on the system through their position, experience
and knowledge of the application area.
The analysis of the requirements often concentrates on the resolution of
conflicts that can occur naturally amongst these stakeholders. Recognising the
need to address and resolve these conflicts is part of the analysis phase of the
requirements engineering process. Prioritisation is also considered at this stage.
The requirements engineer may apply the acronym MoSCoW to the require-
ments, judging each one on a scale of:

Must have

Should have

Could have

Won’t have

When the analysis of the requirements has been completed and the conflicts
have been resolved, validation of the requirements specification checks that they
have been documented correctly and conform to the organisational standards.
The testability of the requirements should be reviewed in conjunction with the
system’s testers, and the wording is checked for ambiguity. Prototyping, which
might have been used earlier in the elicitation phase, can now be repeated to
validate the requirements and models; data flow diagrams, entity models and
any of the analysis techniques used in the elicitation phase will be checked for

Although the process of requirements engineering bears a close resemblance
to that of systems analysis and design, by emphasising the requirements phase of
the life cycle the requirements engineer avoids the pressure to start develop-
ing prematurely. The systems analyst, responsible for both the analysis and the
design of the system, will frequently be urged by management to make crucial
design decisions early in the project life cycle before the implications of the
decision have been fully explored. The elicitation, analysis and validation of
requirements provide a mechanism for avoiding this.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->