3 - requirements and requirements engineering

13
SYSTEMS ENGINEERING MOOC 3 – REQUIREMENTS AND REQUIREMENTS ENGINEERING PART 1 In the last two modules we introduced systems, the system life cycle, and systems engineering. In particular, we looked at the relevance and benefits of systems engineering. Before we look at the various systems engineering activities in more detail in forthcoming modules, in this presentation we look at what we mean when we refer to the ‘needs’ and ‘requirements’ for a system. We will also consider in this module how we might go about developing a set of requirements—we call that process ‘requirements engineering’. When describing the system, we make the distinction between needs and requirements: Needs are generally capabilities stated in the language of business management or stakeholders at the business operations levels. Requirements are formal statements that are structured and can be validated—there may be more than one requirement that can be defined for any need. Requirements are generated from needs through a process of requirements analysis (which is also called business analysis or mission analysis at the higher levels). 1

Upload: yashar2500

Post on 07-Feb-2016

52 views

Category:

Documents


0 download

DESCRIPTION

3 - Requirements and Requirements Engineering

TRANSCRIPT

Page 1: 3 - Requirements and Requirements Engineering

SYSTEMS ENGINEERING

MOOC 3 – REQUIREMENTS AND REQUIREMENTS ENGINEERING

PART 1In the last two modules we introduced systems, the system life cycle, and systems engineering. In particular, we looked at the relevance and benefits ofsystems engineering.

Before we look at the various systems engineering activities in more detail in forthcoming modules, in this presentation we look at what we mean when we refer to the ‘needs’ and ‘requirements’ for a system. We will also consider in this module how we might go about developing a set of requirements—we call that process ‘requirements engineering’.

When describing the system, we make the distinctionbetween needs and requirements:

Needs are generally capabilities stated in the language of business management or stakeholders atthe business operations levels.

Requirements are formal statements that are structured and can be validated—there may be morethan one requirement that can be defined for any need.

Requirements are generated from needs through a process of requirements analysis (which is also calledbusiness analysis or mission analysis at the higher levels).

1

Page 2: 3 - Requirements and Requirements Engineering

Needs and requirements exist at a number of levels.

There is an enterprise view (in which enterprise leadership sets the enterprise strategies and concepts of operations); a business management view (in which business management derive businessneeds and constraints as well as formalize their requirements); a business operations view (in which stakeholders define their needs and requirements); and a systems view (in which the system is defined inlogical and physical views). Subsequently, of course, there are the views at the lower-level of the subsystem and other system elements.

As illustrated here, the enterprise, business management, and business operations views are in the problem domain; the system and subsystem (andlower) views are in the solution domain.

As we discussed in earlier modules, the problem domain is generally considered to be the responsibility of those who have ownership of the problem to be solved, so the descriptions of the system are predominantly in the language of the customer’s business management and business operations, focusing on what the system needs to be able to do, how well it should be done, and why—these descriptions are called logical (or often functional) descriptions. On the other hand, the solution domain is generally considered to be the responsibility of those implementing the solution, so the descriptions of the system in that domain are predominantly in engineering and physical terms, focusing on how the problem is to be solved—that is,how it will look once it has been implemented. Theselatter descriptions are called physical descriptions.

At the highest level, the enterprise has a number of strategies that will guide its future.

From our perspective, our system has its genesis in the Concept of Operations (ConOps) which communicates the leadership’s intentions with regard to the operation of the organisation—in termsof existing systems and systems to be developed.

2

Page 3: 3 - Requirements and Requirements Engineering

The Business Needs and Requirements (BNR) Definition Process begins with the organization’s vision, goals and objectives communicated by the ConOps.

Business management uses this guidance to define Business Needs, largely in the form of Preliminary Life-cycle Concept Documents (PLCD), which capture the Preliminary Acquisition Concept, Preliminary Operational Concept (the Preliminary OpsCon), Preliminary Deployment Concept, Preliminary Support Concept, and Preliminary Retirement Concept.

Let’s look at those life-cycle concepts in a little more detail.

The Operations Concept (OpsCon) describes what thesystem will do, how well and why (from the perspective of the user).

The Acquisition Concept describes the way the system will be acquired including aspects such as stakeholder engagement, requirements definition, solicitation and contracting issues, design, production, and verification.

The Deployment Concept describes the way the system will be validated, delivered, and introduced into operations.

The Support Concept describes the desired support infrastructure and manpower considerations for supporting the system after it is deployed. A support concept addresses operating support, engineering support, maintenance support, supply support and training support.

The Retirement Concept describes the way the system will be removed from operation and retired, including the disposal of any hazardous materials used in or resulting from the process.

At this early stage, business management prepare draft, or preliminary concepts, that will be fleshed out late by stakeholders at the business operations level.

3

Page 4: 3 - Requirements and Requirements Engineering

First, however, the Business Needs contained in the Preliminary Life-cycle Concepts are elaborated and formalized into Business Requirements, which are documented in the Business Requirements Specification (BRS), which is also called the Business Requirement Document.

The process by which business needs are transformed into business requirements is called mission analysis or business analysis.

Once business management are satisfied that their needs and requirements are reasonably complete, they pass them on to the business operations level. Here, the Stakeholder Needs and Requirements (SNR)Definition Process uses the ConOps and the other PLCD as guidance.

Requirements engineers lead stakeholders from the business operations level through a structured process to elicit Stakeholder Needs—in the form of a refined OpsCon document and other Life-cycle Concept Documents (LCD).

Stakeholder needs are then transformed into a formal set of Stakeholder Requirements, which are documented in the Stakeholder Requirement Specification (StRS).

That transformation is guided by a formal process of requirements analysis.

At the system level, in the System Requirements Definition Process, the requirements in the StRS are then transformed by requirements engineers into System Requirements, which are documented in the System Requirement Specification (SyRS) (also referred to as the Solution Requirement Specification Document, or simply the System Specification).

Note that the figure illustrates that a number of SyRS may be derived from the StRS. Also note that some organizations may prepare individual LCD for each of a number of systems that are developed to meet the Business Needs.

4

Page 5: 3 - Requirements and Requirements Engineering

The process then continues for the system elements. As we observed earlier, the requirements are now physical requirements as they relate to the elements of the system rather than the system itself.

PART 2We have talked about needs and requirements and how we use business and requirements analysis to translate between them at the various levels. Let us now look at that process in a little more detail. Let’s start with some definitions that will assist.

First, we have to recognize that terms such as system and system element are level-specific, so we need a term that can apply at any level and to any single thing at that level, whether an enterprise, business unit, system, system element (which could be a human or organisation), or process.

So we define an entity as:

An entity is a single thing to which a need or requirement refers: an enterprise, business unit, system, system element (which could be a product, process, human, or organisation).

A need can then be defined as the result of a formal transformation of one or more concepts for an entity into an agreed-to expectation for that entity to perform some function or possess some quality (within specified constraints).

So what then is a requirement?

A requirement is the result of a formal transformation of one or more needs into an agreed-to obligation for an entity to perform some function or possess some quality (within specified constraints). It is common to refer to two major categories of requirement.

The first is a functional requirement—something thatthe system should do or provide.

The remaining types of requirements are called non-functional requirements—which refer to some...

5

Page 6: 3 - Requirements and Requirements Engineering

...property, quality or attribute that the system must possess, a condition the system must meet, or a constraint under which it must operate or be developed.

One type of requirement that is commonly included as a non-functional requirement is a constraint.

A constraint is some restriction or bound: under which the system should operate, or on the way in which the system is to be developed.

As I said, constraints are most commonly included in the category of non-functional requirements, but sometimes they are listed separately.

Requirement statements should not be written in isolation but should be supported by:Performance, verification, and rationale statements supporting each requirement.Definitions of other systems with which the system must integrate and to which it must interface.Information about the application domain within which the system must operate.

Requirement statements have the same structure and follow the same rules, regardless of the level at which they are written. It should be noted, however, that the requirements in the BRS and the StRS are not as formal as those in the SyRS.

Let’s look in a little more detail at performance requirements, verification requirements and rationale statements. First, performance requirements.

Having decided what the system must do, the designer must now determine how well the system isto perform each of those functional requirements.

A good discipline is to ensure that, every time a functional requirement is articulated, at least one corresponding performance statement is made.

Most of the operational functions will have obvious performance parameters associated with them such as speed, accuracy, endurance, and acceleration.

6

Page 7: 3 - Requirements and Requirements Engineering

The definition of functional and performance requirements is not complete until verification requirements are also included.

Every time a functional requirement is articulated (with appropriate performance statement(s)), it is good practice for a corresponding verification statement to be made.

It is often difficult to write verification requirements for system-level functions, but the discipline of doing so is important since there is little point in stating a requirement for a function without consideration of how the function is to be tested. An additional benefit of adhering to the discipline at this stage is that test plans become much easier to write because the tests required at any level can be considered within a framework provided by an aggregation of the verification requirements at that level.

The rationale for a requirement is the reason why therequirement exists.

The rationale may record the design decision(s) leading to the requirements, the assumptions behindit, or something as simple as the logic behind the selection of the numbers in the statement (for example, why they have been rounded to two decimal places).

A requirement should not be accepted unless the rationale is well understood.

As well as these broad categories, an adjective is often included to describe the nature of the requirement. So, reference is often made to operational requirements, stakeholder requirements, environmental requirements, interface requirements,system requirements, regulatory requirements, safety requirements, design requirements, and many more other categories of requirements.

7

Page 8: 3 - Requirements and Requirements Engineering

In general, a requirement should be a statement of what a system should do, rather than how it should do it.However, this is often too simplistic in practice, because:it may be essential that the system should perform a function in a particular way (for example, for interoperability, to meet extant standards, etc)a specific statement is often less easily confused thanan abstract statement of the problemthe specifiers of the system are often the domain experts—they are therefore best placed to state howthe system should be developed and how it should operate

So why do we need requirements—well there are a number of reasons.

First, we need to be able to define a scope for the project. How else would we know what the system is to do?

Then, we need to ensure that everyone involved has had input and the various points of view have been reconciled.

We also need to be able to justify any expenditure of funds or effort based on the need to achieve an endorsed set of requirements.

We need to be able to report on progress.

And, finally, we need to be able to tell when we are finished (or when the contractor is finished).

Let’s now look at some other major definitions. We have used some of these terms already in a general sense—here we define them more precisely.

8

Page 9: 3 - Requirements and Requirements Engineering

A user is someone who is involved in using the system once it has been developed. Strictly speaking users are part of the system (as are materials, facilities, data, software and hardware). Users are sometimes called actors. Users include operators, maintainers, etc.

The customer is the organisation that is paying for the system to be developed.

The acquirer is the entity acquiring the system. Because the users are normally too busy with operational tasks, the do not have time (or the expertise) to acquire new systems. Large customer organisations will therefore most likely have a separate acquisition organisation.

The developer is the entity responsible for developing the products that make up a system (software, hardware, documentation, and so on).

The contractor—the organisation within which the development is conducted, normally under contract with the customer. The customer could have an in-house developer, but most organisations outsource development to a contractor.

A stakeholder—someone who has a right to influence the requirements (often, someone affectedby the system). Users are invariably stakeholders. Other stakeholders may include management, clients, the public, and so on.

We have discussed needs and requirements. Let us now turn to requirements engineering.

9

Page 10: 3 - Requirements and Requirements Engineering

As illustrated here, requirements engineering is the formal process through which we move from the enterprise strategies to the system requirements, first by formally translating the business requirements into stakeholder requirements and then the stakeholder requirements into system requirements.

We saw earlier why we need requirements. We need requirements engineering to ensure that we can get those requirements.

We need to be able to guarantee that we have a complete set of requirements that are unambiguous, complete, and non-conflicting.

We must be able to trade off functionality for cost—which implies that we understand the required functionality, priorities, and costs.

We need to be able to manage changes in requirements for a wide variety of reasons.

PART 3Before we leave requirements, it is common to consider two additional aspects of requirements and requirements engineering.

First, there are certain characteristics we desire from a well-formed requirement. Second, we often append to the requirement statement one or more attributes which will help us manage the requirement statement and the set of statements.

Let’s look first at the characteristics of a well-formed requirement.

Desirably, to be useful, each requirement statement should exhibit all of the following characteristics:

Necessary. The requirement must be necessary in that the system could not function in the desired waywithout this requirement. It also follows that a requirement cannot be necessary if it cannot be traced back to a higher-level requirement (and the associated need).

Singular. A requirement cannot be a combination of two or more requirements—that is the...

10

Page 11: 3 - Requirements and Requirements Engineering

... requirements set must be normalized so that requirements do not overlap. This also implies that the requirement is concise and clear.

Correct. That the requirement must be correct is axiomatic—an incorrect requirement will result in a system that does not meet the real requirements.

Unambiguous. All readers of the requirement should come to the same understanding of what the requirement is saying—there can be only one interpretation. This is difficult, particularly in English, where one statement can have more than one meaning.

Feasible. A requirement must be achievable using existing technologies and manufacturing.

Additionally, a requirement statement must be:

Appropriate to Level. Each requirement must be appropriate to the level at which it is stated. That is, for example, if it is a system-level statement, it should not refer to sub-system properties.

Complete. The requirement must stand alone and should not need further explanation.

Conforming. Each requirement must conform to a standard formal structure as defined by the organisation, or perhaps in accordance with an external standard.

Verifiable. Each requirement must be verifiable, in that it can be proved that the system meets or possesses the requirement. Verification may be by one or more means.

To support analysis and management, requirements should be allocated a number of attributes. There can be many attributes attached to a requirement—here we identify a small number of the major attributes:

Unique identifier. Each requirement must be able to be identified as a unique statement.

Short title. It is useful to give the requirement a unique short title, which makes it easy to refer to the content of the requirement as well as making it simpler to display in graphical format such as in the RBS.

Priority. Requirements are often stated in terms of

11

Page 12: 3 - Requirements and Requirements Engineering

their importance to individual stakeholders. The priority of each requirement provides some design space within which to work during requirements analysis and negotiation.

Risk. Each requirement contributes to overall system risk in its own way.

Source. The originator (person, organization, document, or process) must be recorded to ensure that all requirements can be justified.

Rationale. A rationale must be recorded for each requirement to record the reason for its existence. Rationale is essential to guide subsequent design.

History. This portion identifies any changes that are made to the requirement throughout the design process.

Relationship to other requirements. The relationship with other requirements must be identified to assist in forward and backward traceability.

Other information. Each requirement should be stored with the date of raising, the status (proposed, reviewed, accepted, rejected), and comments.

Finally, it is often useful to add a type attribute so that the requirements can be considered n various logical groupings that are useful in their management.

Examples include such types as input, output, external interfaces, reliability, availability, maintainability, accessibility, environmental conditions, ergonomic, safety, security, facility, transportability, training, documentation, testing, and so on.

Finally in this module, we make brief reference of what we call emergent properties of a system. That is, we have to recognise that when we develop a system it will have certain properties that are those that are possessed by the system as a whole but are not obvious in any of the elements or interconnections. These properties therefore only emerge after all the individual system elements have been integrated. These emergent properties cannot be exhibited by elements of the system in isolation because they depend on interactions between those elements, including interaction with their environment.

12

Page 13: 3 - Requirements and Requirements Engineering

Examples of emergent properties are: maintainability, reliability, usability, security, and so on.

Perhaps the bicycle is one of the best examples of a system that possesses emergent properties since it can only perform its principal function when all system elements, including the rider, have been integrated. If any one of the major subsystems is removed, the system cannot function.

We are interested in emergent properties because they must be defined from the top down—they cannot be obtained by specifying requirements for individual system elements and then hoping that the desired properties will exist on integration. That is, for example, we must start by saying the system is safe and then decide how the constituent system elements contribute to that safety rather than make all the elements safe and hope that the resulting system is therefore safe.

Of course we also must consider the possibility of thecompleted system exhibiting emergent properties that were not considered as part of its design and, in some cases, may be undesirable in the completed product.

In this module, we have discussed requirements—the levels at which they exist and the relationship between them at each of those level. We looked at a number of definitions and then finished with an introduction to requirements engineering. In the nextmodule, we will look in more detail how to create and validate a set of requirements.

13