A requirement is something that a computer application must do for its users. It is a specific function, feature, quality, or principle that the system must provide in order for it to merit its existence. Requirements constitute part of the scope of a software development project. Add a few requirements, and the scope increases ; take some away, and the scope decreases. The requirements also dictate how the system should respond to user interaction. It should do specific things when poked or prodded by the user in a certain way. Requirements often seem abstract and intangible, especially to software developers. Requirements and design tend to blur together in a software person's brain until they become indistinguishable. However, it is crucial to keep requirements and design separate. Following are some of the ways IT people typically get off track with requirements:
For clarification of this thorny issue, let's look again at the unfortunate requirements shown earlier in Table 1.1. This time let's look at them in detail and try to identify those things that do not constitute high-quality requirements.
This requirement is too vague. How could it translate into a valuable constraint on the design of an application? It implies that the fiscal year has some impact on how customer transactions are organized, but we are not sure what impact. In fact, what is a "customer transaction"? We understand that this system has some type of data entry, but that must be stated more specifically . Maybe this is a suggestion about volume, meaning that old transactions can't be archived until they are a year old, but that interpretation is a stretch from looking at this requirement.
Saying "restricted" access is OK, but details about the restriction (who can, who can't) must be stated clearly in this context. Also vague is the reference to remote inquiry. How remote? Saying "remote access" when referring to mobile employees working in the field but still within a couple of miles of the office is one thing ”but talking about worldwide access is yet another. Implications on the system design and architecture could be huge.
This requirement makes several technical assumptions concerning the design. Barcoding is a solution to a problem, not a requirement. This system probably needs a way to identify each document uniquely, but it doesn't have to be barcodes. If all the existing systems use document barcoding (not the case with this system), it would make sense to write a nonfunctional requirement that states, "Unique identification of all documents will be done through barcoding." What's the difference? By embedding the barcoding assumption in various functional requirements, you make it difficult for someone to change the identification method from barcoding to glyphs, optical character recognition (OCR), or some other technology, thereby reducing your ability to respond to user needs discovered later in the process. Another sticky point in this requirement is the reference to work queues. This seems to make an assumption about a workflow-oriented system. Workflow tools are solutions, not requirements. A better way to put it might have been, "At a minimum, the unique identification will ensure routing to a specific worker in the organization when the documents are returned."
Look at the reference to a workflow . Our suspicions were right! The requirements document has already specified a workflow solution in its requirements. Actually, this whole entry is suspicious. It seems to be saying that we must cache documents by two different criteria: by type or by process. The criteria are good requirements, but the caching (or prefetching ) is really a solution to address performance problems and probably is not a requirement in itself.
This requirement assumes the presence of a journal file, which has entries put into it when a letter is created. This requirement seems focused on the front end ("do this") instead of the back end ("in order to get this"). Why put entries into a journal file? You might do that so that you could create a list of all the letters that were created, when, and by whom. You really want the ability to audit letters written. Looking at it from the back end actually makes for a better, clearer requirement. You could create a journal file, but don't think about that until design!
Again, this requirement seems more focused on the how than the what . Rather than look at the different steps a system must go through, it should clearly document the end in mind. Here is our rewrite for this requirement: "When a new document image is brought into the system, it should be routed to the worker who has the account open for the same SSN as the new document and should be made obvious to that worker. If no worker has an open account, the document should be made available to any worker." You will also see that none of the requirements in our list are linked to a business person. It would be very difficult to pinpoint "who cares" about each of these requirements. Who are the computer users who will gain value from these requirements? The answers to these questions are not clear from these requirement statements. But why not include design in requirements? Why do we keep harping on keeping design out of requirements? There are several reasons. First, skill sets for a development project are matched to the activity performed. Therefore, the people who are gathering requirements probably have skills that are not suited to design or development. Furthermore, the designers/developers may not have the skills to conduct good quality user interviews and requirements planning sessions. It is also important to keep these activities separate because the design ultimately must be based on the requirements of the business. Documenting requirements is an effort in understanding the problem at hand. Designing is the activity of solving the problem. The solution for the problem must come after the problem has been identified, documented, understood , and agreed on. This can be tricky, especially in an iterative/incremental lifecycle. Perhaps a more accurate way to state our rule is that no system, subsystem, or increment should proceed into design until the requirements for that system, subsystem, or increment have been identified, documented, and understood . (Clumsy sentence structure, but good advice.) When design precedes requirements, or supplants them, the system takes on requirements of its own ”requirements that are neither documented nor representative of the users' needs. The end result can be a wasted design effort, an unusable system, missed milestones, and unhappy users. Not knowing the problem that your design is solving is dangerous business. It is always advisable (if difficult) to define the problem completely before designing. Another reason to keep design out of requirements gathering is related to the team environment. If a group is designing a system with no documented requirements, it is likely that group members will be working with different goals in mind. Because they do not have a common document from which to begin, they form the requirements picture in their own minds and use that to formulate their designs. These designs almost certainly will be incompatible and overlapping, causing integration problems, skipped requirements, scope creep, schedule issues, and unhappy users. 1.2.1 Functional Requirements
Functional requirements are what the users need for the system to work. Functional requirements are functions and features. These are the requirements we typically think of when we describe systems. Here are some sample functional requirements for an order entry system:
Use cases, the subject of this book, are one way to document functional requirements. We'll examine alternatives to use cases later in this chapter. 1.2.2 Nonfunctional RequirementsNonfunctional requirements address the hidden areas of the system that are important to the users even though they may not realize it. As you can probably judge by the name , these requirements do not deal with the functionality of a system. Nonfunctional requirements are the global, fuzzy factors or principles that relate to the system's overall success. Many of them end in -ility , so we sometimes call the collection of them the -ilities . An example of an -ility is scalability: the ability of the system to handle an increased workload without significantly increasing the transaction processing time. (See Section 4.2.10 for details.) |