SYSTEMS ENGINEERING

MOOC 4 REQUIREMENTS AND REQUIREMENTS ENGINEERING

PART 1

We saw earlier that 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 structurethe RBS) that will assist in developing these hierarchies.

First, however, lets look at the process by which the needs and requirements are related to each other at the various levels of a hierarchy.

A functional hierarchy is produced through two principal processes: elicitation and elaboration.

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 explicitthat is, they are largely given to us directly by the business or the stakeholders or are taken directly from come constraint.

1

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:

Decomposition entails breaking a higher-level function into those lower-level functions that are explicitly required by it.

Derivation entails requirements engineers drawing some inference. That is, business management or thestakeholders did not state the function directly, but the derived function is a necessary part of the systemdesign if one or more of the directly stated functions are to be met.

The elicitation and elaboration tasks are not for novicesthat is particularly true for elaboration. To undertake them properly, requirements engineers (orbusiness analysts) must understand:

the business,the application domain, the specific problem, the needs and constraints of system stakeholders, acquisition and project management,requirements engineering and systems engineering, andthe technologies and engineering involved.

You can see by this list that such skill sets rarely happen by accident and must be deliberately developed.

By way of simple example, consider an upper-level statement of the mission of a medical centre.

The ACME Medical Centre is to provide a selectedrange of Medical Services in a secure and

comfortable environment, in order to attain anominated Profit.

The following functions are decomposed (that is, theyare explicit in the statementhere highlighted in red bold font): Provide selected range of medical servicesProvide a secure environmentProvide a comfortable environmentAttain nominated profit level

2

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 tobe achieved):Provide medical centre infrastructureManage medical centre and its servicesSupport medical services

Needs and requirements can be identified by:

Structured workshops are the most useful for early designthey 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.

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.

Interviews should be considered as one-on-one workshopsthat is, they should be structured in thatthey should start with strawman artifacts, and have an agenda.

Surveys/questionnaires do not have a great return rate (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.

Use cases and operational scenarios are an excellent way to identify detailed needs and requirements. Wehumans are natural story tellers, so it is a useful way to ask stakeholders to describe their engagement with the system to be developed.

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.

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:

observation of work studies (time and motion studies)participation in work activitiesobservation of the systems organisational and political environment ...

3

technical documentation reviewmarket analysiscompetitive system assessmentreverse engineeringbenchmark processes and systems

4

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:

Verificationwhich ensures that the system at any stage matches the specifications we have developed for itthat is, we have built the system right

Validationwhich ensures that the system meets the original business needs and requirementsthat is, we have also built the right system.

Often these two associated aims are combined into the term verification and validation (V&V).

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).

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.

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 isboth 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

5

Acquisition Phase to support the design and development effort. DT&E activities may also occur during the Utilization Phase to support activities suchas the development of modifications.

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.

Operational test and evaluation (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.

PART 2

Lets now look at the important function of requirements management.

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 mustbe managed as they are developedstakeholder requirements change over the life of the systemthe business may change

6

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 systems requirements are modified before it is put into service.

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.

A requirements management tool:

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 alsoto retrieve specific requirements and to generate reports of subsets of requirements based on selectedcriteria.

The tool should support forward and backward traceability to allow investigation of how a higher-level requirement is achieved as well as to identify the origin of any lower-level requirement.

Requirements engineers need the support of the toolto 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 anyparticular requirements engineering process.

7

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.

Here we call the requirements framework the requirements breakdown structure (RBS)also calledthe 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 deliverthe 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.

8

The principal benefit of the functional hierarchy is that it provides a framework within which requirements can be developed and tracedalso 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 intuitionsince 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 are5 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.

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

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 thatthe 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

9

numbering system so that parent requirements can be traced to their children and vice versa.

Here is an example of an RBSin 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.

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

Some general rules for developing FFBDs:

The FFBDs should be displayed as a hierarchical elaboration.

The level of the FFBD illustrated should be such that the portion displayed should be visible on a single A4sheet of paper, at no less than 10-point font.

As with the RBS, naming of the FFDB elements should be consistent.

The FFBDs also make use of a hierarchical numbering system. Where possible, the same numbering systemis to be used in the RBS and the FFBDs.

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 appliedit 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.

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.

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

Through forward traceability, design decisions can betraced 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.

11

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.

Well, it has been a bit of a hard slog, but we have now covered all the basics we need to allow is to lookat the life cycle phases in mode detail. In the next module, Ian will begin out discussion of the Acquisition Phase by examining Conceptual Design.

12