Unit 2 - Requirements concepts Flashcards
Where and when does the requirements engineering process take place in an iterative and incremental development process?
The main output of a requirements engineering process is the contract between those commissioning the system and the developers of the system. It has therefore to take place early in the software development process. However, an iterative and incremental process recognises that requirements are not stable and revisiting, clarifying and specifying requirements occur in parallel with the other phases of development.
SAQ1
Identify the stakeholders for a system to book appointments for a hospital.
Hospital administrators, receptionists, doctors, nurses, patients, general public.
SAQ2
Suggest ways in which requirements may evolve.
- new requirements may be added
- existing requirements may change because of changes in the environment or in the organisation
- some requirements may become obsolete
- technologies may evolve
- other systems may emerge that introduce interoperability requirements
- regulations may change
SAQ2
Why is the below not a well expressed requirement?
“The software system should provide acceptable performance under maximum load conditions.”
The requirement is ambiguous and not verifiable. How can performance be measured? What is maximum load?
SAQ 3
Why is the below not a well expressed requirement?
“If the system fails in operation there should be minimal loss of data.”
The requirement is ambiguous and not verifiable. What is minimal loss of data?
SAQ 3
Why is the below not a well expressed requirement?
“The software should be developed so that it can be used by inexperienced users.”
The requirement is ambiguous. What are the usability criteria?
SAQ 3
What are requirements and stakeholders and how do they relate to each other?
Requirements are the functions and qualities that are wanted of a product. Stakeholders are the people and organisations with a vested interest in the product. Requirements arise from stakeholders’ needs.
SAQ 4
What are the benefits of documenting requirements within a project?
Requirements record decisions. They are the main reference for what should be built and the basis for validation of the built system. Therefore they need to be documented so that they can be used throughout development.
SAQ 4
What is an agile approach to requirements engineering documentation?
In an agile approach, requirements documentation serves a purpose and should be done only to the extent that it contributes to that purpose. It should serve as a vehicle for common understanding, communication and future traceability.
SAQ 5
Which other activities will be taking place in parallel with requirements engineering?
The definition of the system architecture and an elaboration of tests for the requirements. When defining requirements there are implications for the architecture of the system and each requirement will be related to some test of the final system.
SAQ6
What are the purposes of requirements?
Communication – from the requirements engineer to the designer. As a contract with the client (and other stakeholders) for what the system must do.
SAQ7
What is a functional requirement?
A functional requirement describes an action that the product must take if it is to carry out the work it is intended to do.
SAQ7
Indicate one property that a functional requirement should not possess?
A functional requirement should not be a statement about a general property such as usability, reliability or maintainability. A functional requirement should not be about the implementation of a solution.
SAQ7
What is a non-functional requirement?
A non-functional requirement is a requirement about a quality that the product must have.
SAQ7
What are a technical solution requirement and a business functional requirement? Why is it useful to distinguish them?
A technical solution requirement is a constraint on the product resulting from the technology of the solution that must be adopted. Business functional requirements are a specification of the work,or business, independent of the way that work will be carried out.
The two types of requirement therefore arise from different domains – the business domain and the solution domain. It is important to keep issues related to the business separate from those of the solution.
SAQ7
What overarching property should the set of functional requirements that result from a requirements-gathering process possess?
The set of functional requirements must fully describe the actions that the intended product should perform. That is, the product’s builder must be able to construct the product desired by the client from the descriptions contained in the functional requirements.
SAQ7
How do business events and use cases help in determining functional requirements?
One way to discover the requirements of a system is to use the steps in use case scenarios. Use cases are derived from business events and each use case is described by a set of scenarios. Each step in a scenario details a functional task. All the functional requirements associated with a use case can be collected from these tasks.
SAQ7
How do user stories help in determining functional requirements?
User stories are written by the people who will get some value out of the system and therefore highlight elements of functionality relevant to them. User stories encourage communication and involvement of users and customers with the development process, allowing for change and discovery of requirements throughout.
SAQ7
How do you discover whether or not a set of functional requirements is sufficient for the product to be useful and whether the functionality is correct?
Ask the user.
SAQ 8
Why must functional requirements be testable?
So that it is possible to determine whether the delivered product meets the intention of the user.
SAQ 8
Can you think of some generic questions to ask that can help in making requirements precise and complete?
Questions of the form ‘when should something happen?’ and ‘to whom should something be sent?’ are useful. You may have thought of others.
SAQ 8
What is the major problem with a requirement that is written in a natural language such as English?
Ambiguity.
SAQ 8
Is it possible or desirable to avoid ambiguity entirely in a
requirements specification? What steps can you take to reduce ambiguity in a requirements specification?
It might be possible to avoid ambiguity entirely, but the cost of being so precise can be enormous and the result unreadable. To avoid ambiguity attention has to be given to the language used to represent requirements.
SAQ 8
Why record the meaning of business and technical words in a requirements specification?
To avoid ambiguity and aid clarity in the usage of terms.
SAQ 8