4-Requirements and Requirements Engineering

Question 1

Hierarchy

Answer 1

needs and requirements can be captured in logical or functional hierarchies. At the end of this module we look briefly at a tool (called the requirements breakdown structure—the RBS) that will assist in developing these hierarchies.

Question 2

Elicitation

Answer 2

Elicited elements are able to be directly attributed to the source and are normally gathered via interview or workshop. An elicited element could also, however, be drawn directly from some constraint (such as a regulation, for example). Elicited elements
are explicit—that is, they are largely given to us directly by the business or the stakeholders or are taken directly from come constraint.

Question 3

Elaboration

Answer 3

Elaboration, on the other hand, involves analysis which would conclude in some element that is necessary as a result of the business or stakeholder intentions.

This analysis is either decomposition or derivation:

1. Decomposition entails breaking a higher-level function into those lower-level functions that are explicitly required by it.
2. Derivation entails requirements engineers drawing some inference. That is, business management or the stakeholders did not state the function directly, but the derived function is a necessary part of the system design if one or more of the directly stated functions are to be met.

Question 4

Elicitation and Elaboration is for novices?

Answer 4

NO! requirements engineers (or business analysts) must understand:

1. the business,
2. the application domain,
3. the specific problem,
4. the needs and constraints of system stakeholders,
5. acquisition and project management,
6. requirements engineering and systems engineering, and
7. the technologies and engineering involved.

Question 5

Example of Elicitation and Elaboration 1

Answer 5

The ACME Medical Centre is to provide a selected range of Medical Services in a secure and comfortable environment, in order to attain a nominated Profit.
The following functions are decomposed (that is, they are explicit in the statement—here highlighted in bold font):

• Provide selected range of medical services
• Provide a secure environment
• Provide a comfortable environment
• Attain nominated profit level

Question 6

2nd Example Derivation

Answer 6

The following functions are derived (that is, they
have not been stated explicitly in the statement but
are necessary functions if the explicit functions are to
be achieved):

• Provide medical centre infrastructure
• Manage medical centre and its services
• Support medical services

Question 7

Technics to identify Needs & Requirements

Answer 7

Needs and requirements can be identified by:

1. Structured workshops are the most useful for early design—they are almost certainly the fastest and most efficient way. Workshops should start with strawman artifacts that are fine-tuned and augmented throughout the assigned period.
   Workshops should be facilitated where possible to ensure they run smoothly.
2. Brainstorming and problem-solving sessions can be considered to be unstructured structured workshops and are therefore really only useful early on to assist in the development of initial artifacts.
3. Interviews should be considered as one-on-one workshops—that is, they should be structured in that they should start with strawman artifacts, and have an agenda.
4. Surveys/questionnaires do not have a great returnrate (somewhere in the vicinity of 10-20%) so they are not good ways of ensuring that all stakeholder views are represented; but questionnaires are a good way of ensuring that the widest number of participants have at least the opportunity to contribute.
5. Use cases and operational scenarios are an excellent way to identify detailed needs and requirements. We humans are natural story tellers, so it is a useful way to ask stakeholders to describe their engagement with the system to be developed.
6. Similarly, when we are at a sufficiently low level in the design, simulations, models and prototypes are useful ways to understand needs and requirements as well as to conduct various trade studies and analyses.
7. The remainder of the activities are relatively low level and are not really useful until we are well into Preliminary Design. Such efforts can include:
   
   1. observation of work studies (time and motion studies)
   2. participation in work activities
   3. observation of the system’s organizational and political environment
   4. market review
   5. competitive system assessment
   6. reverse engenieering
   7. benchmark processes and systems

Question 8

What the customer have to do before accept the system?

Answer 8

Returning to our diagram showing how requirements engineering assists in the development of requirements, we can now work backwards. Before the customer accepts the system from the contractor, the delivered system is verified against the System Specification (the SyRS).

Question 9

VERIFICATION AND VALIDATION

Answer 9

The entire systems engineering process aims to produce a system that is both verified against the documentation produced during the systems engineering process, and validated against the original needs and requirements that initiated the system development in the first case. So, there are two principal acts: Verification—which ensures that the system at any stage matches the specifications we have developed for it—that is, we have ‘built the system right’ Validation—which ensures that the system meets the original business needs and requirements—that is, we have also ‘built the right system’.

Question 10

What the customer have to do before accept the system?

Answer 10

Returning to our diagram showing how requirements engineering assists in the development of requirements, we can now work backwards. Before the customer accepts the system from the contractor, the delivered system is verified against the System Specification (the SyRS).

Question 11

Check to do before to put into service

Answer 11

Before the system can be put into service, however, it must be validated against the stakeholder needs and requirements (the StRS) and the business needs and requirements to ensure that those needs and requirements are met.

Question 12

Test and Evaluation

Answer 12

Verification and validation is underpinned by a well managed approach to test and evaluation (T&E), which aims to support the delivery of a system that is both verified and validated. There are three major categories of T&E that are applied to coincide broadly with the activities of the Acquisition Phase, the transition between the Acquisition and Utilization Phases, and the Retirement Phase. Developmental test and evaluation (DT&E). DT&E refers to the T&E activities undertaken during the Acquisition Phase to support the design and development effort. DT&E activities may also occur during the Utilization Phase to support activities such as the development of modifications.

Question 13

what is the acceptance test?

Answer 13

Acceptance test and evaluation (AT&E). AT&E represents the formal testing conducted to enable the customer to verify the system and to accept it from the developer. AT&E effectively forms the boundary or transition between the Acquisition Phase and the Utilization Phase and, as such, is an important contribution to FQR.

Question 14

Operational Test and Evaluation

Answer 14

(OT&E). Once the systems is accepted from the developer, OT&E may be conducted under realistic operational conditions by operational personnel in order to validate the capability system. OT&E is normally conducted for a period of time following acceptance of the system by the customer from the contractor (that is, after AT&E) and before introduction into service.

Question 15

Requirement Management

Answer 15

Requirements management is the process by which changes to requirements are managed throughout the system lifecycle. Requirements change because: they are derived from the stakeholder need and must be managed as they are developed stakeholder requirements change over the life of the system the business may change the environment will no doubt change over the lifecycle laws and regulations will change over the life of the project It is often the case that more than 50% of a system’s requirements are modified before it is put into service.

Question 16

Requirement Management TOOL

Answer 16

A requirements management tool is generally necessary to assist in the management of the large number of requirements. It is almost impossible to have requirements traceability without implementing the requirements in some automated context.

Question 17

Requirement Management TOOL characteristics

Answer 17

Supports elicitation and allows requirements engineers to capture requirements as they are gathered Once the requirements are captured, the tool should allow readers to browse the requirement set but also to retrieve specific requirements and to generate reports of subsets of requirements based on selected criteria. The tool should support forward and backward traceability to allow investigation of how a higherlevel requirement is achieved as well as to identify the origin of any lower-level requirement. Requirements engineers need the support of the tool to generate good requirements with the appropriate spelling, punctuation, and use of glossary and template items. Requirement sets also need to be delivered in a variety of formats so it is important that the tool allows import and export of requirements in various formats such as word-processing and spread-sheet. The tool should support change control and change impact assessment as well as the functional allocation and functional-to-physical translation. It is also important that the tool does not enforce any particular requirements engineering process.

Question 18

Other TOOLS

Answer 18

There are a large number of tools that may assist in requirements engineering, including the context diagram, functional flow block diagrams (FFBD), requirements breakdown structure (RBS), and N2 diagrams. Other tools include structured analysis, data flow diagrams (DFD), control flow diagrams (CFD), IDEF diagrams, behaviour diagrams, action diagrams, state/mode diagrams, process flow diagrams, function hierarchy diagrams, state transition diagrams (STD), entity relationship diagrams (ERD), structured analysis and design, object-oriented analysis (OOA), unified modelling language (UML), structured systems analysis and design methodology (SSADM), and quality function deployment (QFD). Here we focus on the RBS and the FFBD.

Question 19

RBS – Requirements Breakdown Structure

Answer 19

Here we call the requirements framework the requirements breakdown structure (RBS)—also called the functional hierarchy. The words are deliberately chosen to differentiate this structure from the well-known project management document called the work breakdown structure (WBS). The RBS is grouped logically (functionally), whereas the WBS is structured by physical work packages for… …the configuration items that will combine to deliver the system and contains other project-related work. At the end of Preliminary Design, the logical groupings of the RBS are then allocated to the physical groupings of the CIs in the WBS.

Question 20

Requirements Flowdown

Answer 20

The principal benefit of the functional hierarchy is that it provides a framework within which requirements can be developed and traced—also called requirements flowdown. The hierarchy is a tree (in maths we call it a directed graph) in which branches flow from the mission statement at the top to the lowest level needs and requirements (which are the leaves of the tree at the bottom). At each level, we stay at a level of abstraction that remains within our intuition—since wwe can only hold in our working memory half a dozen key concepts, the framework encourages us to start with a mission statement within which there are 5 to 7 key concepts. Each of those concepts is fleshied out as a statement at the next level, leading to 5-7 goal statements, each of which contains 5-7 concepts, each of which can then be fleshed out as an objective statement, each of which has 5-7 key concepts, and so on. The process continues until we reach the leaves of the tree.

Question 21

RBS – Requirements Breakdown Structure Diagram

Answer 21

If we look at that tree more formally, we can see that the addition of a numbering system allows each level to be associated with the level above and below.

Question 22

Rules for developing RBS

Answer 22

Some general rules for developing the RBS: The RBS is to be displayed hierarchically. The level of the RBS illustrated should be such that the portion displayed should be visible on a single A4 sheet of paper, at no less than 10-point font. Naming of RBS elements should be consistent so that the key-word phrases are verb-based. The length of the key-word phrases should be……consistent (three or four words are normally sufficient). Each key-word phrase must be unique (since it must be fleshed out into a unique requirement). Elements should be numbered with a hierarchical numbering system so that parent requirements can be traced to their children and vice versa.

Question 23

Example RBS

Answer 23

xample of an RBS—in this case, for a domestic security alarm as part of our house. If we look across the five elements at the first level we can see the major functions of the alarm. If we look at the next level, the RBS shows the functions that combine to form each parent function at the level above. As you can see from this diagram, the RBS is powerful tool to illustrate the functionality to be provided by the system.

Question 24

FFBDs

Answer 24

The hierarchical representation of requirements in the RBS can be supported by FFBDs to show the flow between functions.

Question 25

Example FFBD

Answer 25

Here is an example portion of a first draft of an FFBD,
as it has been prepared in a workshop with
stakeholders. Note that the functions have yet to be
formally written and the numbering system has yet
to be applied—it is often best to capture the
functions informally and then formalise them than it
is to try to capture them in some formal template.
10
Note that the FFBDs are very good ways of capturing
the operational scenarios from which the needs and
requirements will be developed.
Unlike the RBS which just show logical relationships,
the FFBDs provide the requirements engineer with
information about the sequencing of functions,
which is of great assistance when identifying
interfaces.

Question 26

REQUIREMENTS TRACEABILITY

Answer 26

Requirements cannot be managed effectively
without requirements traceability.
Traceability ensures that we know where the
requirement came from, what requirements are
related to it, and what requirements were derived
from it.
Good traceability allows us to identify all
requirements affected by a change, for example.

Question 27

Differences between FORWARD and BACKWARD

Answer 27

Broadly, there are two types of traceability: forward
traceability and backward traceability.
Forwards traceability gives us confidence that each
requirement has been addressed in the design.
Backwards traceability allows us to trace from each
requirement back to at least one requirement in the
parent document

Question 28

FORWARD Traceability

Answer 28

Through forward traceability, design decisions can be
traced from any given system-level requirement (a
parent requirement) down to a detailed design
decision (a child requirement).
For each requirement, we must be able to find at
least one child in the subordinate design documents.
If there is more than one child, we must be able to
identify all of them.

Question 29

BACKWARD Traceability

Answer 29

Backward traceability ensures that additional
requirements (not formally endorsed by the
customer) have not crept (through requirements
creep) into the design.
Any aspect of the design that cannot be traced back
to a higher-level requirement is likely to represent
unnecessary work for which the customer is most
probably paying a premium.
An orphan requirement is out-of-scope.