Module 4.

Requirement Discipline INSY 55: System Analysis and Design

4.

This module focuses on the requirements discipline in Systems Analysis and Design. It
explains about the discipline prominent in terms of elaboration phase, it includes models in related
with business concern and provides a fresh perspective to a problem and build credibility with
users within the organization.

At the end of this module, students should be able to:

1. determine system requirements through review of documentation, interviews,

observation, prototypes, questionnaires, vendor research, and joint application
design sessions;
2. discuss the need for validation of system requirements to ensure accuracy and
completeness and the use of a structured walkthrough;
3. establish and maintain agreement with the customers and other stakeholders on
what the system should do;
4. provide system developers with a better understanding of the system requirements.
5. define the boundaries of (delimit) the system;
6. provide a basis for planning the technical contents of iterations;
7. provide a basis for estimating cost and time to develop the system; and
8. define a user-interface for the system, focusing on the needs and goals of the users.

 Unified Modeling Language (UML) - a general-purpose, developmental, modeling

language in the field of software engineering that is intended to provide a standard
way to visualize the design of a system.
 Prototype - an early sample, model, or release of a product built to test a concept
or process. It is a term used in a variety of contexts, including semantics, design,
electronics, and software programming.
 System requirements - are all of the requirements at the system level that describe
the functions which the system as a whole should fulfill to satisfy the stakeholder
needs and requirements, and are expressed in an appropriate combination of
textual statements, views, and non-functional requirements; the latter expressing
the levels of safety, security, reliability, etc., that will be necessary.
 Descriptive Models - describes logical relationships, such as the system's whole-
part relationship that defines its parts tree, the interconnection between its parts, the
functions that its components perform, or the test cases that are used to verify the
system requirements.
Module 4. Requirement Discipline INSY 55: System Analysis and Design

 Analytical Models - describes mathematical relationships, such as differential

equations that support quantifiable analysis about the system parameters.

4.1 The Requirements Discipline

The Requirements discipline provides the primary input for Analysis and Design. The
Implementation discipline implements the design. The Test discipline tests system designed during
Analysis and Design. The Environment discipline develops and maintains the supporting artifacts
that are used during Analysis and Design.

4.1.1 The Requirements Discipline in More Details

Figure 1. Activities of the Requirements Discpline

a. Gather Detailed Information

 Analysts need to dialog with users of new system
 Analysts should dialog with users of similar systems
 Analysts must read documentation on existing system
 Develop expertise in business area system will support
 Other technical information should be collected
 Computer usage, work locations, system interfaces, and software packages

b. Define Requirements
 Models record/communicate functional requirements
 Modeling continues while information is gathered
 Process of refining is source of learning for analyst
Module 4. Requirement Discipline INSY 55: System Analysis and Design

 Specific models built depend on developing system

 The UP provides a set of possible model types
o Some model types satisfy object-oriented requirements
o Analysts select models suited to project and skill-set

c. Prioritize Requirements
 Users tend to request sizeable number of functions
 Scarcity of resources limit function implementation
 Scope creep: tendency of function list to grow
 Scope creep adversely impacts project
o Leads to cost overruns
o May also cause implementation delays
 Prioritization of functions antidote to scope creep

d. Develop User Interface Dialogs

 Interface as a sensory bridge to physical machine
 Users familiar with functionality of interface
 User feedback on new interface is reliable
 Interface dialogs
o Model elicits and validate interface requirements
o May be paper storyboards or prototype

e. Evaluate Requirements with Users

 Models built and validated as per user requirements
 Process is iterative
 Alternative models developed and continually revised

 Focus shifts from defining to realizing objectives

 Activities spread over many iterations of UP
 Requirements activities linked to other disciplines:
o design, implementation, and testing
 Output of iteration within elaboration phase is working software

4.1.2 System Requirements

System requirements are all of the requirements at the system level that describe the
functions which the system as a whole should fulfill to satisfy the stakeholder needs and
requirements, and are expressed in an appropriate combination of textual statements, views, and
non-functional requirements; the latter expressing the levels of safety, security, reliability, etc., that
will be necessary.
System requirements play major roles in systems engineering, as they:

 Form the basis of system architecture and design activities.

 Form the basis of system integration and verification activities.
 Act as reference for validation and stakeholder acceptance.
 Provide a means of communication between the various technical staff that interact
throughout the project.
Elicitation of stakeholder requirements starts in Concept Definition and will be initially
developed through interview and mission analysis. System requirements are considered in detail
during System Definition. Neither can be considered complete until consistency between the two
has been achieved, as demonstrated by traceability, for which a number of iterations may be
needed.
Module 4. Requirement Discipline INSY 55: System Analysis and Design

a. Definition and Purpose of Requirements

A requirement is a statement that identifies a product or processes operational,
functional, or design characteristic or constraint, which is unambiguous, testable, or
measurable and necessary for product or process acceptability (ISO 2007).

To avoid confusion in the multitude of terms pertaining to requirements, consider the

following classifications:

 Process Role or State: The role the requirement plays in the definition process; for
instance, its position in the system block (e.g. translated, derived, satisfied) or its
state of agreement (e.g. proposed, approved, cancelled).
 Level of Abstraction: The level within the definition process that the requirement
stands; for instance, stakeholder requirement, system requirement, system element
requirement.
 Type of Requirement: The nature of the requirement itself; for instance, functional,
performance, constraint, etc.

b. Traceability and the Assignment of System Requirements during Architecture and

Design
Requirements traceability provides the ability to track information from the origin of the
stakeholder requirements, to the top level of requirements and other system definition elements
at all levels of the system hierarchy. Traceability is also used to provide an understanding as to
the extent of a change as an input when impact analyses are performed in cases of proposed
engineering improvements or requests for change.
During architecture definition and design, the assignment of requirements from one level to
lower levels in the system hierarchy can be accomplished using several methods, as
appropriate - see Table 1.

Table 1. Assessment Types for a System Requirement

Assignment Type for a
Description
System Requirement
Direct Assignment The system requirement from the higher level is directly assigned to a
system or a system element for a lower level (e.g. the color used to paint
visible parts of the product).
Indirect Assignment The system requirement is distributed across several systems or system
(Simply Decomposed) elements and the sum of a more complex calculation for distribution is equal
to the requirement of higher level (e.g. a mass requirement, power
distribution, reliability allocation, etc.) with sufficient margin or tolerance. A
documented and configuration-managed "assignment budget" for each
assignment must be maintained.
Indirect Assignment The system requirement is distributed to several systems or system
(Modeled and elements using an analysis or mathematical modeling technique. The
Decomposed) resulting design parameters are assigned to the appropriate systems or
system elements (with appropriate margins). For example, in the case of
radar detection requirement that is being analyzed, these lower-level
parameters for output power, beam size, frequencies, etc. will be assigned
to the appropriate hardware and software elements. Again, the analysis (or
model) must be documented and configuration-managed.
Derived Requirement Such system requirements are developed during the design activities as a
(from Design) result of the decision of the design team, not the stakeholder community.
These requirements may include the use of commercial-off-the-shelf (COTS)
items, existing systems or system elements in inventory, common
components, and similar design decisions in order to produce a "best value"
solution for the customer. As such, these derived requirements may not
directly trace to a stakeholder requirement, but they do not conflict with a
stakeholder requirement or a constraint.
Module 4. Requirement Discipline INSY 55: System Analysis and Design

c. Classification of System Requirements

Several classifications of system requirements are possible, depending on the requirements
definition methods and/or the architecture and design methods being applied. (ISO 2011) provides
a classification which is summarized in Table 2 (see references for additional classifications).

Table 2. Example of System Requirements Classification

Types of System
Description
Requirement
Functional Describe qualitatively the system functions or tasks to be performed in operation.
Requirements
Performance Define quantitatively the extent, or how well and under what conditions a function
Requirements or task is to be performed (e.g. rates, velocities). These are quantitative
requirements of system performance and are verifiable individually. Note that
there may be more than one performance requirement associated with a single
function, functional requirement, or task.
Usability Define the quality of system use (e.g. measurable effectiveness, efficiency, and
Requirements satisfaction criteria).
Interface Define how the system is required to interact or to exchange material, energy, or
Requirements information with external systems (external interface), or how system elements
within the system, including human elements, interact with each other (internal
interface). Interface requirements include physical connections (physical
interfaces) with external systems or internal system elements supporting
interactions or exchanges.
Operational Define the operational conditions or properties that are required for the system to
Requirements operate or exist. This type of requirement includes: human factors, ergonomics,
availability, maintainability, reliability, and security.
Modes and/or Define the various operational modes of the system in use and events
States conducting to transitions of modes.
Requirements
Adaptability Define potential extension, growth, or scalability during the life of the system.
Requirements
Physical Define constraints on weight, volume, and dimension applicable to the system
Constraints elements that compose the system.
Design Define the limits on the options that are available to a designer of a solution by
Constraints imposing immovable boundaries and limits (e.g., the system shall incorporate a
legacy or provided system element, or certain data shall be maintained in an
online repository).
Environmental Define the environmental conditions to be encountered by the system in its
Conditions different operational modes. This should address the natural environment (e.g.
wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-
induced environmental effects (e.g. motion, shock, noise, electromagnetism,
thermal, etc.), and threats to societal environment (e.g. legal, political, economic,
social, business, etc.).
Logistical Define the logistical conditions needed by the continuous utilization of the
Requirements system. These requirements include sustainment (provision of facilities, level
support, support personnel, spare parts, training, technical documentation, etc.),
packaging, handling, shipping, transportation.
Policies and Define relevant and applicable organizational policies or regulatory requirements
Regulations that could affect the operation or performance of the system (e.g. labor policies,
reports to regulatory agency, health or safety criteria, etc.).
Cost and Define, for example, the cost of a single exemplar of the system, the expected
Schedule delivery date of the first exemplar, etc.
Constraints
Module 4. Requirement Discipline INSY 55: System Analysis and Design

d. Requirements Management
Requirements management is performed to ensure alignment of the system and system
element requirements with other representations, analyses, and artifacts of the system. It
includes providing an understanding of the requirements, obtaining commitment, managing
changes, maintaining bi-directional traceability among the requirements and with the rest of the
system definition, and alignment with project resources and schedule.
There are many tools available to provide a supporting infrastructure for requirements
management; the best choice is the one that matches the processes of the project or
enterprise. Requirements management is also closely tied to configuration management for
baseline management and control. When the requirements have been defined, documented,
and approved, they need to be put under baseline management and control. The baseline
allows the project to analyze and understand the impact (technical, cost, and schedule) of
ongoing proposed changes.

4.1.3 Models and Modeling

System modeling is the process of developing abstract models of a system, with each
model presenting a different view or perspective of that system. System modeling has now come to
mean representing a system using some kind of graphical notation, which is now almost always
based on notations in the Unified Modeling Language (UML). It also helps the analyst to
understand the functionality of the system and models are used to communicate with customers
 Models are great communicators
o Leverage visual cues to convey information
o Reduce complexity of components to essentials
 Models are configured within a hierarchy
 Model granularity can be adjusted by analyst
 UML activity diagram is one type of model
o Focuses on both user and system activities

Figure 2. An Analyst Needs a Collection of Models to Understand System

Requirements
Module 4. Requirement Discipline INSY 55: System Analysis and Design

4.1.3.1 The Purpose of Models

Models are representations that can aid in defining, analyzing, and communicating a set of
concepts. System models are specifically developed to support analysis, specification, design,
verification, and validation of a system, as well as to communicate certain information. One of the
first principles of modeling is to clearly define the purpose of the model. Some of the purposes that
models can serve throughout the system life cycle are:
 Characterizing an existing system: Many existing systems are poorly documented and
modeling the system can provide a concise way to capture the existing system design. This
information can then be used to facilitate system maintenance or to assess the system with
the goal of improving it. This is analogous to creating an architectural model of an old
building with overlays for electrical, plumbing, and structure before proceeding to upgrade it
to new standards to withstand earthquakes.

 Mission and system concept formulation and evaluation: Models can be applied early
in the system life cycle to synthesize and evaluate alternative mission and system
concepts. This includes clearly and unambiguously defining the system's mission and the
value it is expected to deliver to its beneficiaries. Models can be used to explore a trade-
space by modeling alternative system designs and assessing the impact of critical system
parameters such as weight, speed, accuracy, reliability, and cost on the overall measures
of merit. In addition to bounding the system design parameters, models can also be used to
validate that the system requirements meet stakeholder needs before proceeding with later
life cycle activities such as synthesizing the detailed system design.

 System design synthesis and requirements flowdown: Models can be used to support
architecting system solutions, as well as flow mission and system requirements down to
system components. Different models may be required to address different aspects of the
system design and respond to the broad range of system requirements. This may include
models that specify functional, interface, performance, and physical requirements, as well
as other non-functional requirements such as reliability, maintainability, safety, and security.

 Support for system integration and verification: Models can be used to support
integration of the hardware and software components into a system, as well as to support
verification that the system satisfies its requirements. This often involves integrating lower
level hardware and software design models with system-level design models which verify
that system requirements are satisfied. System integration and verification may also include
replacing selected hardware and design models with actual hardware and software
products in order to incrementally verify that system requirements are satisfied. This is
referred to as hardware-in-the-loop testing and software-in-the-loop testing. Models can
also be used to define the test cases (glossary) and other aspects of the test program to
assist in test planning and execution.

 Support for training: Models can be used to simulate various aspects of the system to
help train users to interact with the system. Users may be operators, maintainers, or other
stakeholders. Models may be a basis for developing a simulator of the system with varying
degrees of fidelity to represent user interaction in different usage scenarios.

 Knowledge capture and system design evolution: Models can provide an effective
means for capturing knowledge about the system and retaining it as part of organizational
knowledge. This knowledge, which can be reused and evolved, provides a basis for
supporting the evolution of the system, such as changing system requirements in the face
of emerging, relevant technologies, new applications, and new customers. Models can also
enable the capture of families of products.
Module 4. Requirement Discipline INSY 55: System Analysis and Design

Figure 3. Reasons for Modeling

4.1.3.2 Types of Models

There are many different types of models and associated modeling languages to address different
aspects of a system and different types of systems. Since different models serve different
purposes, a classification of models can be useful for selecting the right type of model for the
intended purpose and scope.

Formal versus Informal Models

Since a system model is a representation of a system, many different expressions that vary
in degrees of formalism could be considered models. In particular, one could draw a picture of a
system and consider it a model. Similarly, one could write a description of a system in text and
refer to that as a model. Both examples are representations of a system. However, unless there is
some agreement on the meaning of the terms, there is a potential lack of precision and the
possibility of ambiguity in the representation.
The primary focus of system modeling is to use models supported by a well-defined
modeling language. While less formal representations can be useful, a model must meet certain
expectations for it to be considered within the scope of model-based systems engineering (MBSE).
In particular, the initial classification distinguishes between informal and formal models as
supported by a modeling language with a defined syntax and the semantics for the relevant
domain of interest.

Physical Models versus Abstract Models

The United States “Department of Defense Modeling and Simulation (M&S) Glossary” asserts that
“a model can be [a] physical, mathematical, or otherwise logical representation of a system”
(1998). This definition provides a starting point for a high-level model classification. A physical
model is a concrete representation that is distinguished from the mathematical and logical models,
both of which are more abstract representations of the system. The abstract model can be further
classified as descriptive (similar to logical) or analytical (similar to mathematical). Some example
models are shown in Figure 4.
Module 4. Requirement Discipline INSY 55: System Analysis and Design

Figure 4. Model-Based Systems Engineering

 Descriptive Models
A descriptive model describes logical relationships, such as the system's whole-part
relationship that defines its parts tree, the interconnection between its parts, the functions
that its components perform, or the test cases that are used to verify the system
requirements. Typical descriptive models may include those that describe the functional or
physical architecture of a system, or the three-dimensional geometric representation of a
system.

 Analytical Models
An analytical model describes mathematical relationships, such as differential
equations that support quantifiable analysis about the system parameters. Analytical
models can be further classified into dynamic and static models. Dynamic models
describe the time-varying state of a system, whereas static models perform computations
that do not represent the time-varying state of a system. A dynamic model may represent
the performance of a system, such as the aircraft position, velocity, acceleration, and fuel
consumption over time. A static model may represent the mass properties estimate or
reliability prediction of a system or component.
 Hybrid Descriptive and Analytical Models
A particular model may include descriptive and analytical aspects as described
above, but models may favor one aspect or the other. The logical relationships of a
descriptive model can also be analyzed, and inferences can be made to reason about the
system. Nevertheless, logical analysis provides different insights than a quantitative
analysis of system parameters.

 Graphical Models
Graphical models provide instant information. Supplement abstract language of data
processing Unified Modeling Language (UML) and Provides standards for object-oriented
models.

Figure 5 - Some Descriptive Models

Module 4. Requirement Discipline INSY 55: System Analysis and Design

Overview of Models Used in Requirements and Design

 Logical models specify processes

 Physical models are based on logical models
o Implement some component of the system
o Included within the design discipline
 UML diagrams are used in system development
 Additional models also used

Figure 6. UML Diagrams used for Modeling

Module 4. Requirement Discipline INSY 55: System Analysis and Design

Figure 7. Additional Models used for Requirements and Design Disciplines

Techniques for Information Gathering

 Questioning, observing, researching, modeling
 Good questions initiate process
 Questions center around three themes
o What are business processes?
o How is the business process performed?
o What information is required?

Figure 8. The Relationship between Information Gathering and Model Building

Module 4. Requirement Discipline INSY 55: System Analysis and Design

Figure 9. Sample Themes for Defining Requirements

 Review reports, forms, procedure, descriptions

 Several sources:
o Internal business documents and procedure descriptions
o Other companies and professional organizations
o Industry journals and magazines reporting “best practices”
 Analysts should validate discovered information with system users

Figure 10. A Sample Order Form for Rocky Mountain Outfitters

 Conduct interviews and discussions with the users

 Break up interview into three phases:
o Preparation
o Enactment
o Follow-up
 Analyst should become familiar with interview protocols
Module 4. Requirement Discipline INSY 55: System Analysis and Design

Figure 11. A Sample Checklist to Prepare for User Interviews

Figure 12. Sample Interview Session Agenda

 Unobtrusively observe business processes

 Diagram all information gathered
 Sample diagram: representation of workflow
o Identify agents to create the appropriate swimlanes
o Represent steps of workflow with appropriate ovals
o Connect activity ovals with arrows to show direction
o Use decision symbol to represent either/or situation
o Use synchronization bars for parallel paths
Module 4. Requirement Discipline INSY 55: System Analysis and Design

Figure 13. A Simple Activity Diagram to Demonstrate a Workflow

Figure 14. An Activity Diagram Showing Concurrent Paths

 Building effective prototypes

o Operative
o Focused
o Quickly composed (especially using CASE tools)
 Distribute and Collect Questionnaires
 Conduct Joint Application Design Sessions (JAD)
Module 4. Requirement Discipline INSY 55: System Analysis and Design

o Includes JAD Session Leader, users, technical staff, project team members

Figure 15. A Sample Questionnaire

Figure 16. A JAD Facility

 Research Vendor Solutions as a two-step process

 Develop list of providers from various sources
Module 4. Requirement Discipline INSY 55: System Analysis and Design

o Directories
o Recommendations
o Journals, magazines, and trade shoes
 Research the details of each solution

Validating the Requirements

Two basic approaches to validating requirements

 Predictive development
o Requirements assumed stable and feasible
o Requirements specified and validated beforehand

 Adaptive development (embodied in UP)

o Requirements are assumed difficult to document
o Requirements subject to change
o System prototypes used in validation process

 Alternatives to developing costly prototypes

o Structured walkthrough and mathematical models

 Structured walkthrough
o Reviews findings
o Reviews models based on findings
o Objective: find errors and problems
o Purpose: ensure that model is correct

 Setting structured walkthrough parameters

o Determine documents to be reviewed
o Determine frequency or schedule
o Select analyst to be reviewed and reviewers

 Conducting structured walkthrough

o Preparation
o Execution
o Follow-up

***End of the Chapter***

Module 4. Requirement Discipline INSY 55: System Analysis and Design

Figure 17. A Structured Walkthrough Evaluation Form

Summary
 System requirements: functional and nonfunctional

 Discipline activities: information gathering, definition, prioritization, and evaluation of

requirements, and the development of user interface dialogs.

 Models: reduce complexity and promote learning

 Model types: mathematical, descriptive, graphical

 UML: standard modeling notation

 Seven primary techniques for gathering information

 One technique to ensure information correctness

 Prototype: working model of a more complex entity

 Joint application design (JAD): comprehensive information gathering technique

 Validate by testing prototypes or completing structured walkthroughs