Requirement-Levels in Software Requirement Engineering
- 1. Requirement Levels By Dr. Ansar Siddiq
- 3. Requirement Levels • Business Requirements: focus on business objectives of the organization or the customer who requests the system Suppose an airline wants to reduce airport counter staff costs by 25 percent This goal might lead to the idea of building a kiosk that passengers can use to check in for their flights at the airport • the business requirements are recorded in vision and scope document Example: Develop a cutting-edge medical device to address a specific healthcare need
- 4. Requirement Levels User requirements: describe goals or tasks the users must be able to perform with the product that will provide value to someone • User requirements describe what the user will be able to do with the system • actual user representatives provide this information • Ways to represent user requirements include use cases, user stories and event response tables Example: I want to check in for a flight so I can board my airplane Use Case: Check in for flight
- 5. Requirement Levels Functional requirements: (what the system does) • specify the behaviors the product will exhibit under specific conditions • describe what the developers must implement to enable users to accomplish their tasks (user requirements), thereby satisfying the business requirements • this alignment among the three levels of requirements is essential for project success Examples: • The Passenger shall be able to print boarding passes for all flight segments for which he has checked in • If the Passenger's profile does not indicate a seating preference, the reservation system shall assign a seat
- 6. Requirement Levels System Requirements: • describe the requirements for a product that is composed of multiple subsystems • A system can be all software or it can include both software and hardware subsystems • Requirements for the system or product as a whole, then, • lead the business analyst to derive specific functionality that must be allocated to one or another of those component subsystems, a • s well as demanding an understanding of the interfaces between them.
- 7. Requirement Levels • Business rules include corporate policies, government regulations, industry standards, and computational algorithms • business rules are not themselves software requirements • But they dictate that the system must contain functionality to comply with the pertinent rules • business rules are the origin of specific quality attributes that are then implemented in functionality (corporate security policies) • you can trace the origin of certain functional requirements back to a particular business rule
- 8. Requirement Levels Non-Functional Requirements: (how well it does the things) • describe the product's characteristics in various dimensions that are important either to users or to developers and maintainers •performance, safety, availability, and portability , and many other characteristics •external interfaces between the system and the outside world •design and implementation constraints •nonfunctional requirements address the environment in which the system operates, such as platform, portability, compatibility, and constraints •compliance, regulatory, and certification requirements •localization requirements for products that must take into account the cultures, languages, laws, currencies, terminology, spelling, and other characteristics of users
- 9. Feature • A feature consists of one or more logically related system capabilities that provide • value to a user • and are described by a set of functional requirements • A feature can encompass multiple user requirements, • Each of which implies that certain functional requirements must be implemented • to allow the user to perform the task described by each user requirement
- 10. Relationship among features, user requirements, and functional requirements
- 11. Text Editor – next version (Project) • A business requirement might be "Increase non-US sales by 25 percent within 6 months • Marketing realizes that the competitive products only have English- language spelling checkers , so they decide that the new version will include a multilanguage spelling checker feature • Corresponding user requirements might include tasks such as • Select language for spelling checker, • Find spelling errors, • Add a word to a dictionary
- 12. Text Editor – next version (Project) • The spelling checker has many individual functional requirements, which deal with operations such as • highlighting misspelled words, • autocorrect, • displaying suggested replacements, and • globally replacing misspelled words with corrected words
Editor's Notes
- #2: This model is not all-inclusive, but it does provide a helpful scheme for organizing the requirements knowledge you'll encounter Instead, think of them simply as containers in which to store requirements knowledge. Such a container could indeed be a traditional document, or it could be a spreadsheet, a set of diagrams, a database, a requirements management tool, or some combination of these.
- #3: why the organization is implementing the system-the business benefits the organization hopes to achieve Business requirements typically come from the funding sponsor for a project, the acquiring customer, the manager of the actual users, the marketing department, or a product visionary Other strategic guiding documents sometimes used for this purpose include a project charter, business, case, and market (or marketing) requirements document Software requirements include three distinct levels: business requirements, user requirements, and functional requirements
- #5: The functional requirements are evident: they describe the observable behavior of the system under various conditions Functional requirements often are written in the form of the traditional "shall" statements The business analyst (BA) documents functional requirements in a soft ware requirements specification (SRS), which describes as fully as necessary the expected behavior of the software system The SRS is used in development, testing, quality assurance, project management, and related project An SRS could be a report generated from information stored in a requirements management tool People call this deliverable by many different names, including business requirements document, functional spec, requirements document, and others Because it is an industry-standard term, we will use "SRS" consistently throughout this book (ISO/IEC/IEEE 2011). functions
- #6: A "system" in this sense is not just any information system People and processes are part of a system, too, so certain system functions might be allocated to human beings A good example of a "system" is the cashier's workstation in a supermarket. There's a bar code scanner integrated with a scale, as well as a hand-held bar code scanner. The cashier has a keyboard, a display, and a cash drawer. You'll see a card reader and PIN pad for your loyalty card and credit or debit card, and perhaps a change dispenser. You might see up to three printers for your purchase receipt, credit card receipt, and coupons you don't care about. These hardware devices are all interacting under software control.
- #7: business rules are not themselves software requirements because they have an existence beyond the boundaries of any specific software application they often dictate that the system must contain functionality to comply with the pertinent rules Sometimes, as with corporate security policies, business rules are the origin of specific quality attributes that are then implemented in functionality
- #11: To illustrate some of these various kinds of requirements