Requirements
Process
We use the ECommerce application from our website as a prototype to illustrate the requirements process. Prototypes represent one way to reduce some of the risks involved in developing a new software solution. In this section, we review the basics of the requirements process as a means to assure success in software solution design and implementation.
The Unified Process is the most popular and widely recognized. This method is by far the most widely accepted to develop the blueprints for building a software product for commercial sales or for internal use as an information system. In our example, we cover almost all of the basics, but we do not go into the many details of managing this process. Experience as well as exposure to the enormous amount of literature, these are the best teachers for anyone to learn the science and craft of requirements process or, more generally, efficiently developing a successful information management system or product.
We use several sources to produce the complete requirements analysis for the ECommerce application. Our sources are listed in our bibliography.
Overview of the Tools
Used often in the literature describing the Unified Process, the diagram below illustrates some of the key documents needed, their relationships to each other, how one contributes and prepares for the other, as well as the types of requirements used to produce them.
Figure 1:
This diagram also indicates how one document "cascades" or contributes to the next; hence the name "water fall" approach to requirements management. The other main alternative to the water fall approach is the "incremental" in which the development team produces a small first set of functionality and then adds incremental layers. The "water fall" and the "incremental" approaches are not necessarily exclusive. For example, when designing a new product, such as the Ecommerce application we analyze here as an example, using the waterfall approach, most development teams, usually the marketing managers, determine what customers look for most in a particular product and use these most demanded functions as priorities to define the scope of version 1, the first "launch" or "increment" in the product roadmap. Once launched, the first version serves as the basis for soliciting feedback from customers to prioritize the next set of functionality for version 2 and so on.
Risk Management as Requirements Management
Before we jump right into the analysis and design of our Ecommerce application, we need to set the definition of the various types of documents and requirement straight in our mind. These are the tools that help us to deliver a clear, unambiguous understanding of what the developers need to develop so that our business can operate in an efficient manner.
Experts in the field of requirements management, such as Boehm, Papaccio and Leffingwell, estimate that the costs of not using a rigorous requirements management method are as high as 30 to 50 percent of total development costs for rework. It costs far more to fix defects found late in the project than to take more time in the design and analysis for the sake of thorough prevention of errors, as depicted in the bar chart below:
Figure 2:
By using rigorous requirements management early in the development project, we can catch errors early before they cause a huge leveraging effect on rework costs. Maintaining high quality in the requirements process reduces business risks that are often measured in the cost to develop an information system compared to the money it is expected to save. Shortcomings in requirements process pose risk in the success, where success means delivering a product that satisfies the user’s functional and quality expectations at the agreed-on cost and delivery dates.
I doubt that any of us would ask a construction contractor to build a custom $500K house without extensively and rigorously establishing the needs and progressively refining the detailed specifications. Likewise as in home construction, once the construction is underway, changes to the original plan are costly. When it comes to building an information system or product, however, many of us have probably seen situations where people tend to gloss over the planning and design analysis phases even when millions of dollars are at stake. Yet, studies show that errors made during the design phases account for 40 to 60 percent of all defects found in a software system. The benefits of a well managed, rigorous design process, especially the financial and general business benefits, are too numerous to review here. Briefly stated, it has often meant the success or the death of many an organization.
Definition of the Tools and Process
By tools, I mean both the documents and their components, especially the types of requirements. As suggested in Figure 1 above, different types of requirements form differnt types of documents. As the requirements become more detailed, the documents that contain them become more technical. This progressive process to refine the requirements is outlined in Figure 1 above and this is what we do to determine how to build our ECommerce application.
The process begins with high level business requirements that are established by management, especially in the case of an internal information system, by marketing and by customers, especially in the case of software products. As illustrated in Figure 1, once the business requirements of all stakeholders are collected to form an overall vision and scope document, also called an MRD (marketing requirements document), we progressively dig one step deeper into details by developing the use cases that define the user requirements and business rules, the functional and non-functional requirements respectively. All stakeholders negotiate their requirements in an iterative process, as depicted in Figure 3, below, in which a distinction is made between the requirements development process and the management of how these requirements, once drafted, are refined, categorized and prioritized during the negotiations between the interested parties, the stakeholders who are depicted in Figure 6 below.
Figure 3
Moving progressively to more detail in our analysis of the ECommerce application, we find that there are three distinct levels of requirements: business requirements, user requirements, and funtional requirements. You might be interested in Methodology Guidelines for a discussion on how these three main levels of requirements fit into the overall requirements process.
The IEEE defines requirements as the capability needed by a user to solve a problem or achieve an objective. It is a capability that must be met or possessed by a system to satisfy a contract, standard or specification. "A requirement is something that the product must do or a quality that the product must have," according to Robterson, referenced in our bibliography.
Business Requirements
As we develop the requirements for the Ecommerce, we will first establish the business requirements; these are high level organizational objectives or the goals of the customer buying the system. Customers, managers, or the marekting department usually represent the source of the business requirements and these stakeholders are the sponors, the financial supporters. The first step in this semi-sequential process is defining the Vision and Scope of the information management product or system.
User Requirements
We then compile all the use cases that we determine relevant. Use cases are composed of user requirements that describe user goals or tasks that the users must be able to perform with the product. This enables us to design the solution starting with the end-user's perspective. After all, the purpose of the software solution is to serve the needs of the business, its employees and customers. Valuable ways to represent user requirements include use cases, scenario descriptions, and event-response tables. For example, in our ECommerce application, one sub-use case is that the end-user, a buyer, must "enter and store all contact information." User requirements describe each of the many actions that a user must do in the system to complete his or her overall goals.
At this level of analysis, we also compile the Business Rules. Business rules are management prescriptions that transcend and guide the day-to-day business decisions. They reflect business policy. The Online Purchasing Application (OPA) must comply with the business rules. We document business rules in one separate document and refer to them from various other documents to avoid redudancy.
Functional Requirements
Moving deeper into technical details, functional requirements specify our ECommerce application's functionality that the development team must build to enable users to accomplish their tasks and thereby achieve the business requirements. Functional requirements are compiled into a document that is usually called an SRS (software requirements specification). These are the "shall" statements that detail every function. For example, "the application shall enable the end-user to collect products into a shopping cart." The Software Requirements Specification (SRS) document contains the functional requirements. It is very useful to delineate and define the various types of requirements so that we know how to use them in developing our clear instructions to develop the software solution.
Non-Functional Requirements
"Non-functional requirements are properties, or qualities, that the product must have," according to Robertson. Non-functional requirements are categorized further as business rules, quality attributes and constraints.
Business rules
These are corporate policies, government regulations, industry
standards, accounting practices, and the like.
Business rules are not themselves software requirements because they
arise from outside the system. Yet,
they often dictate that the system must contain functionality to comply with
the pertinent rules. They may also
restrict who can perform certain use cases. For
example, in our Ecommerce application, an end-user, the online shopper, will
not determine the shipping charge.
The business rule determines what the shipping charges are for an order based,
for example, on the weight and urgency of delivery.
The online shopper is allowed to merely fill the shopping cart and
confirm the order while an administrative clerk will periodically modify the
shipping charges based on the criteria mentioned above or something similar.
Business rules are often the origin of functional requirements or even of
specific quality attributes that are implemented in functionality.
For this reason, we can often trace the origin of certain functional
requirements back to a particular business rule.
Quality attributes
These augment the description of the product’s functionality by describing the product’s characteristics in ways that help the stakeholder understand more about what is to be developed. For example, in our Ecommerce application, we want the user interface to be self explanatory so that no online buyer will need any training, or even very little online help messages in order to place an order. We also want to be able to change the colors of the ECommerce application easily in order to implement it at any one of our various customers' websites to make it blend in with a consistent look and feel. A functional requirement that might result from this non-functional quality attribute is the use of style sheets which enables us to accomplish this need.
Constraints
These are often statements that impose restrictions on the choices available to the developer for design and construction of the product. For example, in our Ecommerce application, management might indicate that only Microsoft’s SQL server is to be used as the underlying database server for this application or that the application must be built in the .NET environment or that no more than 3,000 online buyers can be logged-on simultaneously.
Features
In our Ecommerce application, the shopping cart metaphor that we use to collect all items in one order, this serves as an example of a feature. A feature is a set of logically related functional requirements that provides a capability to the user and enables the satisfaction of a business objective. Another example of a feature in our Ecommerce application is the set of functions that enable the buyer to use and validate a secured credit card as the means of purchase.
Requirements Development Process
The basic steps in the requirements process are to collect the requirements from the stakeholders, analyze them, develop them into logical, reference-able specifications, and then validate them with all the stakeholders. This might sound like a simple linear process. In practice, these activities are interleaved, incremental, and iterative as shown in Figure 4 below:
Figure 4
Figure 5, below, suggests an overview of steps in the requirements process to prepare, develop and to manage the software solution design. Not strictly sequential, the process begins with the first 7 steps to orient the team and set the definitions and methods to move forward. Steps 8 through 17 are repeated in order to validate and close any gaps of expectations between the stakeholders. Once the initial requirements are developed within the scope of the project that is defined in the Vision and Scope document, we must then manage the requirements and how they evolve and change until early prototypes become the software solution.
Figure 5
For the purposes of our example of Requirements Develop for the ECommerce application, we step through most of this process outlined above in Figure 5. We produce most of the documents suggested in the above figure.
The Analyst
Depending on the size of a project, more than one analyst may be needed. The role of the analyst is to gather, analyze, document, and validate the needs of the project stakeholders. The analyst serves as the communication conduit through which requirements are explained between the customer community and the software development team. The analyst plays a pivotal role in collecting and communicating product information, whereas the project manager takes the lead in managing the project. The analyst’s job is more of a project role than a job title and requires the “right stuff;” he or she must know how to handle all types of people as well as organize, orchestrate and push the requirements process forward.
Figure 6, below, illustrates some of the main groups of stakeholders with which the analyst works to accomplish several goals such as to gather the requirements, to eliminate ambiguity, to set correct expectations and to accomplish tasks and milestones to move the team to the finish line.
Figure 6
Vision and Scope Document
As discussed above, we begin our analysis of our ECommerce application with this document. It collects the business objectives and goals which represent the initial definitions and high level requirements used to set the business purpose and the scope of the software solution. This single document set the stage and, once agreed on by all stakeholders, it kicks off the requirements development process. The Vision and Scope document is also called a project charter or a business case. Software vendor companies often call this document an MRD (marketing requirements document) that goes into more detail about how this software solution, as a product to be sold on the market, will generate revenue and win over competitors.
Usually the owners of this document are the business managers at the highest levels because the development of a new product represents a large investment in funds and personnel resources, especially in marketing and development. New product development carries a huge importance in terms of the overall company strategy, its position and future evolution both financially as well as market wise. At this level, we define clearly the why as well as parts of the what that the programmers have to develop. From this documentation, everyone in the enterprise can understand why the software solution is needed and learn generally what the programmers must develop.
Use Cases
Although the vision and scope gives us a clear and, hopefully detailed, understanding of the business goals of the software solution, it does not present much information about how it must serve the end-users. The Use Cases provide the high-level requirements about what the solution must do to enable the end-users to perform their daily work, enable managers to make timely business decisions and generally contribute to increasing efficiencies for the enterprise. Use Cases represent the starting point of requirements, driven by what the business needs and what the end-users must be able to do with the system as a means to achieve the business goals. We provide the main Use Cases for our ECommerce application to serve as an example. At this level, we define clearly the what that the programmers must build as a business solution. From the Use Case, programmers understand what they must build.
You might be interested in the relatively short white paper, Methodology Guidelines, for a discussion focused mainly on Use Cases as well as on how the Vision and Scope document and the Requirements document fit in with use cases to provide an overview of the requirements process.
Software Requirements Specifications
Finally, we move into the more detailed level of requirements where we form the basis for all project planning, design, and coding. The SRS forms the foundation for system testing and user documentation. The SRS describes in detail and as completely as necessary how to design and develop the software solution. At this level we define the how for the programmers. Programmers should be able to read the SRS and translate the functional specifications into software code. In the SRS, we include several diagrams that enable us to analyze our solution from various perspectives.
The Entity Relationship Diagram