3c-Requirements Engineering Part3

Question 1

2 additional aspects of Requirements Engineering

Answer 1

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

Question 2

Requirements CHARACTERISTICS

Answer 2

1-Necessary. The requirement must be necessary in that the system could not function in the desired way without 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).
2-Singular. A requirement cannot be a combination of
two or more requirements—that is the requirements set must be normalized so that requirements do not overlap. This also implies that the requirement is concise and clear.
3-Correct. That the requirement must be correct is axiomatic—an incorrect requirement will result in a system that does not meet the real requirements.
4-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.
5-Feasible. A requirement must be achievable using
existing technologies and manufacturing.
6-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.
7-Complete. The requirement must stand alone and
should not need further explanation.
8-Conforming. Each requirement must conform to a
standard formal structure as defined by the organisation, or perhaps in accordance with an external standard.
9-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.

Question 3

Requirements ATTRIBUTES

Answer 3

1-Unique identifier. Each requirement must be able to
be identified as a unique statement.
2-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.
3-Priority. Requirements are often stated in terms of their importance to individual stakeholders. The priority of each requirement provides some design space within which to work during requirements analysis and negotiation.
4-Risk. Each requirement contributes to overall system
risk in its own way.
5-Source. The originator (person, organization, document, or process) must be recorded to ensure
that all requirements can be justified.
6-Rationale. A rationale must be recorded for each requirement to record the reason for its existence. Rationale is essential to guide subsequent design.
7-History. This portion identifies any changes that are made to the requirement throughout the design process.
8-Relationship to other requirements. The relationship
with other requirements must be identified to assist in forward and backward traceability.
9-DATE, Status: Each requirement should be stored with the date of raising, the status (proposed, reviewed, accepted, rejected), and comments.
10-Group: 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.

Question 4

EMERGENT PROPERTIES

Answer 4

A system 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.
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. Emergent properties 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 the completed system exhibiting emergent properties