9.

Requirements Phase
Requirements phase is
The first step in the development of any
software system
It is particularly important in the
development of large and very large
software systems where the mental
manageability skills of a single person are
inadequate for the size of the task.
The user's needs must be carefully identified
and documented.
Quality Attributes
(1) Quality attributes exist within complex
systems, and their satisfaction can never be
achieved in isolation. Some of quality
attributes are related each other: e.g.,
security and fault tolerance, portability and
performance.
(2) Types of Quality Attributes:
System qualities that are observed
during the system execute
(performance, security, availability,
functionality, usability)
System qualities that are not discernable
at runtime (modifiability, portability,
reusability, integrability, testability).
Business qualities (time to market) that
are effected by the architecture

different qualities manifest themselves

differently during the phases.
Usability: making the user interface clear
and easy to use is primarily a matter of
getting the details correct because they are
encapsulated within a single component.
Modifiability: determined by how
functionality is divided. A system is
modifiable if changes do not involve a large
number of distinct components.
Performance:
Communication is necessary among
components
Allocated to each components
Choice of algorithms to implement
selected functionality
1.

Quality Attributes discernable at runtime:

How well does the system, during
execution satisfy its behavioral
requirement?
Does it provide the required result?
Does it provide them in a timely enough
manner?
Are the results correct or within specified
accuracy and stability tolerances?
Does the system function as desired when
connected to other systems?
Quality Attributes not discernable at
runtime:
How easy is the system to integrate, test
and modify?
How expensive was it to develop?
What was its time to market?
(3) Quality Attribute & Software Lifecycle:
Quality must be considered at all phases of
design, implementation, and deployment, but

2.

Quality attributes discernable at runtime

Performance: The time required to
respond to stimuli (events) or the
number of events processed in some
interval of time.
Security: A measure of the systems
ability to resist unauthorized attempts
at usage and denial of service while still
providing it services to legitimate user.
Availability: Measures the proportion
of time the system is up and running.
Functionality: The ability of the
system to do the work for which it was
intended. Performing a task requires
that may or most of the systems
components work in a coordinated
manner to complete the job.
Usability: The right information is
available to the user at the right time
Learnability: how quick and easy is it
for a user to learn to use the systems
interface?
Efficiency: Does the system respond
with appropriate speed to a users
request?
Memorability: Can the user remember
how to do system operations between
uses of the system?
Error avoidance: does the system
anticipate and prevent common user
errors?
Error handling: does the system help
the user recover from errors?
Satisfaction: does the system make the
users job easy?
Quality Attributes not Discernable at
Runtime

3.

Modifiability: The ability to make

changes quick and cost effectively
follows directly from the architecture.
Portability: The ability of the system
to run under different computing
environments.
Reusability: The systems structure of
some its components can be reused
again in future applications.
Integrability: The ability to make the
separately developed components of the
system work correctly together.
Interoperability: the ability of a group
of parts (constituting a system) to work
with another system
Testability: To demonstrate its faults
through (typically execution-based)
testing
Business Qualities
Time to market
Cost
Projected lifetime of the system
Targeted market
Rollout schedule
Extensive use of legacy systems

Requirements Analysis:

The requirements analysis stage:

Feasibility Study
Requirements Analysis

Requirements analysis is based on qualities

attributes from different types of
stakeholders
Client managers
End users
Client engineers
Contractors

Questions the analyst asks:

Who are involved and what are their
backgrounds?
What is the current system (if there is
one), what equipment constraints exist,
and what functions are to be
incorporated?
When must the system be completed,
and what are the various timelines for
changing over to the new system,
installation, testing, and training?

What is the anticipated impact in terms

of personnel, training, etc.?
Why is the new system being
developed?
What are the constraints in terms of
cost, etc.?
Answers are gathered via interviews,
observations, etc.
Assessment of system goals are also
required - cut costs, reduce errors, etc.
Requirements analysis should
provide a statement of the requirements
of the problem,
analyze the current situation,

State the goals of the system being

developed.

Requirements Model [Jacopson, 1992]

What? To capture the functional/nonfunctional
requirements from stakeholders perspective
How a potential user will use the system
Specify all the functionality/non-functional
requirements of the system
Traceability through all models
(Requirements model Analysis model
Design model Implementation model
Testing model)
Simple to learn and use
Simplify our understanding of the
system
Powerful to express the information
which is required to model the system
Defined that different people can
discuss the system in terms of these
concepts.
Use Case Model:
Actors: define what exists outside of the
system, represent a certain role (vs. users:
the same may appear as instance of several
different actors)
Use cases: define what should be performed
by the system, sequence of transactions
Controlled by what the users wish to do with
the system
Find out users requirements and preferences
Easy to understand and formulate from the
user perspective
Interface descriptions: (the prototype of user
interface) simulate the use cases for the users by
showing the user the views that the user will see
when executing the user case in the system to be
built.

Domain object model: consist of problem

domain objects and serve to support for the
development of the requirement models.