SWE-Chapter 4: Requirements Engineering
Domain requirements
Constraints on the system from the domain of operation
Functional requirements depend on what ?
Depend on the type of software, expected users and the type of system where the software is used.
( Ways of writing a system requirements specification ) - Graphical notations
Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used.
Requirements elicitation and analysis (Sometimes called requirements elicitation or requirements discovery.)
Involves technical staff working with customers to find out about: the application domain the services that the system should provide and the system's operational constraints.
Requirements specification process
Is the process of writing down the user and system requirements in a requirements document.
Requirements elicitation involve ?!
May involve - end-users, - managers, - engineers involved in maintenance, - domain experts, - trade unions, etc. These are called stakeholders.
quantitative metrics
Quantitative is an adjective that simply means something that can be measured. For example, we can count the number of sheep on a farm or measure the gallons of milk produced by a cow.
Understandability (Domain requirements problems)
Requirements are expressed in the language of the application domain; This is often not understood by software engineers developing the system. (The system safety shall be assured according to standard IEC 60601-1:Medical Electrical Equipment - Part 1:General Requirements for Basic Safety and Essential Performance.)
Non-Functional Organisational requirements
Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.
Non-Functional External requirements
Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc. (These may include regulatory requirements that set out what must be done for the system to be approved for use by a regulator, such as a central bank; legislative requirements that must be followed to ensure that the system operates within the law; and ethical requirements that ensure that the system will be acceptable to its users and the general public.)
Non-Functional Product requirements
Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. (Examples : 1 -include performance requirements on how fast the system must execute and 2- how much memory it requires, 3- reliability requirements that set out the acceptable failure rate, 4- security requirements, and 5 -usability requirements.)
( Ways of writing a system requirements specification ) - Structured natural language
The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement.
( Ways of writing a system requirements specification ) - Natural language sentences
The requirements are written using numbered sentences in natural language. Each sentence should express one requirement.
Non-functional requirements
These define system properties and constraints for example reliability, response time and storage requirements. ( Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.)
( Ways of writing a system requirements specification ) - Mathematical specifications
These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don't understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract.
( Ways of writing a system requirements specification ) - Design description languages
This approach uses a language like a programming language, but with more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications.
Requirements discovery
This is the process of interacting with stakeholders of the system to discover their requirements. Domain requirements from stakeholders and documentation are also discovered during this activity. There are several complementary techniques that can be used for requirements discovery,
(possible users of the document and how they use it. ) Managers
Use the requirements document to plan a bid for the system and to plan the system development process.
(possible users of the document and how they use it. ) System Test Engineers
Use the requirements to develop validation tests for the system.
(possible users of the document and how they use it. ) System Maintenance Engineers
Use the requirements to understand the system and the relationships between its parts.
(possible users of the document and how they use it. ) System Engineers
Use the requirements to understand what system is to be developed.
Alternatively
another option or possibility (used to suggest another possibility)
- Environmental requirements
are environmental constraints imposed by the atmosphere outside of the system boundaries. (Environmental requirements that specify the operating environment of the system window , iOS , os , android )
- development requirements
development process requirements that specify the programming language, the development environment or process standards to be used (swift , java , c++ ....)
interpreted (Ambiguous requirements may be interpreted in different ways by developers and users.)
express
influence (Organisational and political factors may influence the system requirements.)
having an effect or impact on the actions, behavior, opinions, etc., of another or others
objectively (Judges must weigh the evidence logically and objectively.)
in a way that is based on facts and not influenced by personal beliefs or feelings:
Requirements Engineering
is the process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.
coherent / cluster
it is clear and carefully considered / a group of similar things that are close together, sometimes surrounding something:
Functional user requirements
may be high-level statements of what the system should do.
Requirements completeness and consistency principle ?
requirements should be both complete and consistent.
Functional system requirements
should describe the system services in detail. ( Specific details about how a system should work, what inputs create what outputs, and design elements to be implemented. For example, "A system shall do processing of personal information to create user profiles.")
Application Domain
specific environment in which the target product is to operate (as train operation, medical records, e-commerce etc.) (For example, a train control system has to take into account the braking characteristics in different weather conditions.)
Functional requirements mean?
the activities that the system must perform ( Describe functionality or system services )
The requirements themselves are:
the descriptions of the system services and constraints that are generated during the requirements engineering process.
data corruption
the fact of information on a computer being changed so that it is wrong and cannot be used:
The software requirements document
the official statement of what is required of the system developers.
Organisational requirements
things that must be done or standards that must be met
emerge (The requirements change during the analysis process. a New stakeholders may emerge and then he have a new Requirements ) (/ɪˈmɜːdʒ/)
to come out
impose (Ex/ External requirements that impose by central bank )
to officially force a rule, tax, punishment, etc. to be obeyed or received:
Ambiguous (Ambiguous requirements may be interpreted in different ways by developers and users.)
unclear or doubtful in meaning (having more than one meaning )
relate to the emergent properties ( non-functional requirements often relate to the emergent properties of the system and therefore apply to the system as a whole. )
تتعلق بالخصائص الناشئة
Domain requirements problems
• Understandability • Implicitness
What is a requirement?
# In industry, It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical (formal) functional specification.
Users of a requirements document ?
( The requirements document has a diverse set of users, ranging from the senior management of the organization that is paying for the system to the engineers responsible for developing the software.) senior management to engineers responsible for developing the software.
elicitation (Requirements elicitation and analysis This is the process of deriving the systemrequirements through observation of existing systems, discussions with potential users and procurers, task analysis, and so on. This may involve the development of one or more system models and prototypes. These help you understandthe system to be specified.) (/iˌlɪs.ɪˈteɪ.ʃən/)
( in education it's mean the practice of getting a student to provide or remember a fact, response, etc. ratherthan telling them the answer:)
- operational requirements
(Examples include operational process requirements that define ) how the system will be used
(@)Non-functional requirements may affect the overall architecture of a system rather than the individual components.
(T) For example, to ensure that performance requirements are met, you may have to organize the system to minimize communications between components.
The software requirements document Should include ?
(both) 1- a definition of user requirements and 2 - a specification of the system requirements.
bid (managers will Use the requirements document to plan a bid for the system and to plan the system development process.)
(here) an attempt to achieve or get something:
Implicitness
- Domain specialists understand the area so well that they do not think of making the domain requirements explicit. (e.g. The deceleration of the train shall be computed as: D (train) = D (control) + D (gradient) where D (gradient) is 9.81ms2 * compensated gradient/alpha and the values of 9.81ms2 /alpha are known for different types of train.)
Organisational requirements classification
- Environmental requirements - operational requirements - development requirements
Ways of writing a system requirements specification
- Natural language sentences - Structured natural language - Design description languages - Graphical notations - Mathematical specifications
there are a number of generic activities common to all RE processes ?
- Requirements elicitation; - Requirements analysis; - Requirements validation; - Requirements management.
Metrics for specifying nonfunctional requirements
- Speed - Size - Ease of use - Reliability - Robustness - Portability
Problems of requirements analysis
- Stakeholders don't know what they really want. - Stakeholders express requirements in their own terms. - Different stakeholders may have conflicting requirements. - Organisational and political factors may influence the system requirements. - The requirements change during the analysis process. New stakeholders may emerge and the business environment may change.
The processes used for RE vary widely depending on ?
- the application domain - the people involved - the organisation developing the requirements.
Functional requirements types ?
1 - Functional user requirements. 2- Functional system requirements.
Non-Functional Requirements Classifications:
1 - Product requirements 2- Organisational requirements 3- External requirements
Usability requirements, Example
1 -The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized. (Goal) 2- Medical staff shall be able to use all the system functions after four hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use. (Testable non-functional requirement)
Consistent requirements
1- There should be no conflicts or contradictions in the descriptions of the system facilities. 2- The requirements should not have contradictory definitions.
Complete Requirements
1- They should include descriptions of all facilities required. 2- All services required by the users should be defined.
Goal Non-functional requirements
A general intention of the user (such as ease of use. )
Portability
A property of a program that can run on more than one kind of computer.
Verifiable non-functional requirement
A statement using some measure that can be objectively tested.
Robustness (She stressed the robustness of the Swiss banking system. ) (/rəʊˈbʌst.nəs/)
A term used to describe the ability of a program to resist crashing due to incorrect input or incorrect intermediate results. (the quality of being strong)
(possible users of the document and how they use it. ) System Customers
Specify the requirements and read them to check that they meet their needs. Customers specify changes to the requirements.
(@)A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required.
T
(@)Ambiguous requirements may be interpreted in different ways by developers and users.
T
(@)Domain requirements may be new functional requirements, constraints on existing requirements or define specific computations.
T
(@)Goals are helpful to developers as they convey the intentions of the system users.
T
(@)If domain requirements are not satisfied, the system may be unworkable.
T
(@)In practice, it is impossible to produce a complete and consistent requirements document especially for large systems where many stakeholders involves.
T
(@)Non-functional requirements may also generate requirements that restrict existing
T
(@)Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless.
T
(@)Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify.
T
(@)Problems arise when requirements are not precisely stated.
T
(@)Process requirements may also be specified mandating(order) a particular IDE, programming language or development method
T
(@)Whenever possible, you should write (implement) non-functional requirements quantitatively ( in away that can be measured be number )
T
* In practice, RE is an iterative activity in which these processes are interleaved.
T
* The software requirements document It is NOT a design document.
T
*System requirements are more detailed requirements and may include more technical information.
T
*User requirements have to be understandable by end users and customers who do not have a technical background
T
(@)Non-functional requirements often conflict and interact with other functional or non-functional requirements.
T (For example, the authentication requirement obviously requires a card reader to be installed with each computer attached to the system. However, there may be another requirement that requests mobile access to the system from doctors' or nurses' laptops. These are not normally equipped with card readers so, in these circumstances, some alternative authentication method may have to be allowed.)
The system's operational domain imposes requirements on the system.
T (it's called Domain requirements)
* The software requirements document it should set of WHAT the system should do rather than HOW it should do it .
T ( As far as possible)
