Techniques of Managing Software Requirements adopted by the Expert Managers
Requirements describe the capabilities or features that need to be implemented in order for the software to achieve its purpose (solve a business problem, satisfy user needs, etc.). Gathering requirements is one of the most challenging tasks in the software development process. This is due to the size and complexity of modern software products, coupled with the difficulty customers may have when trying to define and then communicate requirements.
Requirements are generally divided into several subcategories, such as business requirements, user requirements, system requirements, performance requirements, deployment requirements, upgrade requirements, security requirements, and so on. Functional requirements describe the features of the software and the tasks it performs. Nonfunctional requirements, also known as quality of service (QoS) requirements, describe properties that the system should display, such as performance, accessibility, or extendibility.
For example, imagine a software development project that is designed to bring the organization�s current accounting system into compliance with new financial legislation.
Few sample requirements can be as given below.
1) A sample business requirement would be “Extend the application to support the new legislation.”
2) A sample user requirement might be “Allow authorized users to produce reports that identify the time, date, reason, and authorization for any financial data changes.”
3) A sample system requirement is “The new application code should be built in Java, connect to the existing MySQL database, and run on the existing server.”
4) A sample deployment requirement is “Establish a process for automatically deploying the modified application to a staging environment for testing, then automatically deploying the application on the mainframe.”
5) A sample upgrade requirement is “The upgrade must preserve all existing data and not require the system to be offline during business hours.”
Once gathered and categorized, all requirements are uniquely labeled, and recorded in the SRS document. This document is used later for prioritizing requirements and for entering them into the requirements management system.
What is the necessity of a structured process for requirements organization?
Requirements explain how the product vision translates into software features. Requirements definition is a critical link between creating the high level purpose for the software development or updating and building a software product that achieves that purpose. Without requirements, it would be difficult to develop effective use cases. Having ineffective or insufficient use cases would complicate application design, and subsequently development. Additionally, it would be more difficult to develop test cases that objectively and effectively verify whether the requirements are implemented correctly and completely in the code.
A process for the requirements organization is necessary because of their quantity and complexity. Storing all the requirements gives those involved in the project a way to access them. Organizing the requirements makes it easier to identify some of the prevailing problems in requirement specifications: they can be ambiguous, incomplete, or even contradictory. For instance, a requirement that states “Implement user-friendly reports” could be considered ambiguous because the definition of “user-friendly reports” is open to multiple interpretations. A requirement that states, “The application must record purchase information in the database” is incomplete unless it is accompanied by information that specifies what purchase information should be stored. An example of potentially contradictory requirements are “Clear all inactive account information after three years” and “Save all purchase information for five years.”
Many functional description and feature description defects could be prevented when requirements are properly gathered and organized. Additionally, the combination of tracking and organizing the requirements creates continuity of information, so that new team members know exactly how the project is defined.
Who should get involved in the requirements process?
All project stakeholders are closely involved in the requirements process. The development and testing team members are involved from the start of the requirements process. Even if the organization has designated roles for the requirement analysts, who specialize in the gathering and organizing of requirements, the developers need to be involved in requirements definition so they will truly understand what they are responsible for implementing. The testing team needs to be involved in the requirements definition so that they can construct the appropriate tests in a timely manner.
What is the methodology of gathering requirements?
First, multiple meetings with customers (for external requirements) or the system architect (for an internal project) are held to establish which categories of requirements are needed, such as functional requirements, quality attributes, constraints, and business rules. As the requirements are gathered, they are organized into the predefined categories. In addition, each feature is broken down into several functional requirements. For instance, returning to the earlier example of the accounting application, one feature might be “Produce a report that lists all changes made to financial data.” Related functional requirements might include “Flag all changes to financial data,” “Record the change made, user, time, date, reason, and approval,” and “Generate an HTML report that provides a table with all change data sorted by date (starting with the most recent).”
A traditional meeting is one out of several requirements elicitation techniques, each of which is effective in different contexts.
Following requirements elicitation techniques listed from the highest relative effectiveness to the lowest are quite useful.
1) Active stakeholder participation
2) On-site customer participation
3) Joint application design, which involves a highly structured meeting
4) Focus groups with actual and/or potential end users
5) Observation of end users performing their daily work
6) Face-to-face interviews with stakeholders who have valuable information to share, but can�t or won�t attend meetings
7) Interviews via telephone, videoconferencing, e-mail, or meeting software
8) Legacy code analysis
9) Reading any legacy system documentation, business documentation, or material related to similar or competing systems
Many More Articles on Test Planning & Management