3b-Requirements Part2 Flashcards
Entity and need definition
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 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 that the system should do or provide. The remaining types of requirements are called nonfunctional requirements—which refer to some 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.
Constraints
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 statement
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.
Verification Statements
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.
Rationale Statements
The rationale for a requirement is the reason why the requirement exists. The rationale may record the design decision(s) leading to the requirements, the assumptions behind it, 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.
Adjective / nature of requirements
For my point of view is a qualification. 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.
REMEMBER What not HOW
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 than an abstract statement of the problem the specifiers of the system are often the domain experts—they are therefore best placed to state how the system should be developed and how it should operate.
why do we need requirements?
1) First, we need to be able to define a scope for the project. How else would we know what the system is to do? 2) Then, we need to ensure that everyone involved has had input and the various points of view have been reconciled. 3) 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. 4) We need to be able to report on progress. 5) And, finally, we need to be able to tell when we are finished (or when the contractor is finished).
Identifying roles like Actors…
1) 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. 2) The customer is the organisation that is paying for the system to be developed. 3) The acquirer is the entity acquiring the system. Because the users are normally too busy with operational tasks, they do not have time (or the expertise) to acquire new systems. Large customer organisations will therefore most likely have a separate acquisition organisation. 4) The developer is the entity responsible for developing the products that make up a system (software, hardware, documentation, and so on). 5) The contractor—the organisation within which the development is conducted, normally under contract with the customer. The customer could have an inhouse developer, but most organisations outsource development to a contractor. 6) A stakeholder—someone who has a right to influence the requirements (often, someone affected by the system). Users are invariably stakeholders. Other stakeholders may include management, clients, the public, and so on.
What is requirements engineering?
It 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.
why we need requirements engineering?
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.
