Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
An overview of requirements engineering, a systematic process for developing software requirements. It covers the tasks of analysis and modeling, the classes of requirements (functional and non-functional), and the importance of precise and complete requirements. It also discusses the challenges of requirements imprecision and the importance of requirements validation.
Typology: Study notes
1 / 36
This page cannot be seen from the preview
Don't miss anything!
cmsc435 - 1
cmsc435 - 3
Functional requirements – What the program does Non-functional requirements – Attributes about the program
cmsc435 - 7
those that absolutely must be met those that are highly desirable but not necessary those that are possible but could be eliminated
cmsc435 - 9
l Functional requirements
Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.
l Non-functional requirements
constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, security requirements, performance, etc.
l Domain requirements
Requirements that come from the application domain of the system and that reflect characteristics of that domain.
cmsc435 - 13
l In principle, requirements should be both complete and consistent.
l Complete
They include descriptions of all facilities required.
l Consistent
There is no conflicts or contradictions in the descriptions of the system facilities.
l In practice, it is impossible to produce a complete and consistent requirements document.
cmsc435 - 15
l Functional: describes an interaction between the system and its environment
l Examples:
System shall communicate with external system X. What conditions must be met for a message to be sent
l Non-functional: describes a restriction or constraint that limits our choices for constructing a solution l Examples: Paychecks distributed no more than 4 hours after initial data are read. System limits access to senior managers.
Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, safety, security, etc.
Requirements which are a consequence of organizational policies and procedures e.g. process standards used, implementation requirements, etc.
Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.
cmsc435 - 19
Property Measure Speed Processed transactions/second User/Event response time Screen refresh time Size M Bytes Number of ROM chips Ease of use Training time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems
cmsc435 - 21
l Constraints are a type of non-functional requirement that is imposed by the client that restricts the implementation of the system or the development process.
l Conflicts between different non-functional requirements are common in complex systems. E.g.,Spacecraft system
cmsc435 - 25
l Lack of clarity - Precision is difficult without making the document difficult to read. l Requirements confusion - Functional and non- functional requirements tend to be mixed-up. l Requirements amalgamation - Several different requirements may be expressed together. l Ambiguity - The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult. l Over-flexibility - The same thing may be said in a number of different ways in the specification. l Lack of modularization - NL structures are inadequate to structure system requirements.
How developers see users How users see developers Users don’t know what they want. Developers don’t understand operational needs. Users can’t articulate what they want. Developers place too much emphasis on technicalities. Users have too many needs that are politically motivated.
Developers try to tell us how to do our jobs.
Users want everything right now. Developers can’t translate clearly-stated needs into a successful system. Users can’t prioritize needs. Developers say no all the time. Users refuse to take responsibility for the system.
Developers are always over budget.
Users are unable to provide a usable statement of needs.
Developers are always late.
Users are not committed to system development projects.
Developers ask users for time and effort, even to the detriment of the users’ important primary duties. Users are unwilling to compromise. Developers set unrealistic standards for requirements definition. Users can’t remain on schedule. Developers are unable to respond quickly to legitimately changing needs.
cmsc435 - 27
cmsc435 - 31
l Based on information assessment (what is required), information collection and report writing.
l Questions for people in the organization
What if the system wasn’t implemented? What are current process problems? How will the proposed system help? What will be the integration problems? Is new technology needed? What skills? What facilities must be supported by the proposed system?
l All involved in the outcome of the system are called Stakeholders (e.g., users, developers, management, contracting organization, funding source).
cmsc435 - 33
Interviewing: In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed. Scenarios are real-life examples of how a system can be used. They should include:
cmsc435 - 37
cmsc435 - 39
l Combine ethnography with prototyping l Prototype development results in unanswered questions which focus the ethnographic analysis. l The problem with ethnography is that it studies existing practices which may have some historical basis which is no longer relevant. l Requirements that are derived from the way that people actually work rather than the way in which process definitions suggest that they ought to work. l Requirements that are derived from cooperation and awareness of other people’s activities.
