Classifying Customer Input, Part 2
In the first part of this two-part series I described some cues that help the business analyst detect when a customer has presented some input that could be classified as a business requirement, use case, business rule, or functional requirement. This article continues the discussion to help you classify customer input into several other categories of requirements knowledge.
Quality Attributes. Statements that indicate how well the system performs some behavior or lets the user take some action are quality attributes, also called quality factors, quality of service requirements, and sometimes simply nonfunctional requirements. Listen for words that describe desirable system characteristics: fast, easy, intuitive, user-friendly, robust, reliable, secure, and efficient. Chapter 12 of my book Software Requirements, 2nd Edition provides guidance on writing quality attributes.
You’ve probably been asked to build user-friendly software, but I’ll bet you’ve never been asked to build user-hostile or user-surly software. Everybody wants user-friendly software. However, it does you no good to write down a requirement that simply states, “The system shall be user-friendly” or robust, or intuitive, or any of these other good things. Those are not useful requirements because we don’t know just what they mean yet. But the customer has an important and legitimate idea behind each requirement, which you’ll need to suss out.
If you hear this sort of vague and fuzzy input, rather than just dismissing it as not useful, regard it as a clue to have a conversation about the statement. Ask the person who provided that input questions such as: “What does user-friendly mean to you? How would we know if this was user-friendly enough? Can you give me some examples of things that you consider as being user-friendly or not user-friendly?” As a BA, you’ll have to work with the users to understand precisely what they mean by these ambiguous and subjective terms so you can write clear, verifiable, and achievable quality goals.
External Interface Requirements. Requirements in this category describe the connections between your system and the rest of the universe. The SRS should include sections for interfaces to users, to hardware devices, and to other software systems, as necessary. Phrases that indicate that the customer is describing an external interface requirement might sound like the following:
- “Must read signals from
“ - “Must send messages to
“ - “Must be able to read (or write) files in
“ - “Must control
“ - “User interface elements must conform to
“
Constraints. Design and implementation constraints legitimately restrict the options available to the developer. Hardware devices having embedded software often must respect physical constraints such as size, weight, and interface connections. It’s a good idea to record the rationale behind each constraint so that all project participants know where it came from and respect its validity. Is it truly a restrictive limitation, as when a device must fit into an existing physical space? Or is it a desirable goal, such as a tablet computer that weighs as little as possible?
Unnecessary constraints inhibit creating the best solution. Excessive constraints also reduce your ability to use commercially-available components as part of the solution. A constraint that specifies that a particular technology be used poses the risk of making a requirement obsolete or unattainable because of changes in the available technologies. Certain constraints can help achieve quality attribute goals. An example is to improve portability by using only the standard commands of a programming language, not permitting vendor-specific extensions.
The following are examples of constraints that you might hear from a customer:
- “Files submitted electronically may not exceed 10 MB in size.”
- “The browser must use 128-bit encryption for all secure transactions.”
- “The database must use the Framalam 10.2 run-time engine.”
Other phrases that suggest the speaker is describing a design or implementation constraint include these:
- “Must be written in “
- “Can’t require more than
“ - “Must operate identically to (or be consistent with)
“ - “Must use “
As with functional requirements, the analyst shouldn’t simply transcribe the user’s statement of a constraint into the SRS. Weak words such as identically and consistent need to be clarified and the real constraint stated precisely enough for developers to act on the information. Ask why the constraint exists, verify its validity (the constraint might be obsolete or based on an incorrect assumption), and document its rationale.
Data Definitions. Whenever customers describe the format, data type, allowed values, or default value for a data item or the composition of a complex business data structure, they’re presenting a data definition. “The ZIP code consists of five digits, followed by an optional hyphen and an optional four digits that default to 0000” is a data definition. Collect these in a data dictionary, a master reference that the team can use throughout the product’s development and maintenance. See Chapter 10 of Software Requirements, 2nd Edition for more about data dictionaries.
Data definitions sometimes lead to functional requirements that the user community did not request directly. What happens when a six-digit order number rolls over from 999999? Developers need to know how the system will handle such data issues. Deferring data-related problems just makes them harder to solve in the future; remember Y2K?.
Solution Ideas. Much of what users present as requirements fits in the category of solution ideas. Someone who describes a specific way to interact with the system to perform some action is presenting a suggested solution. The BA needs to probe below the surface of a solution idea to get to the real requirement. For instance, functional requirements that deal with passwords are just one of several possible solutions for an access control requirement.
Suppose you’re working on the requirements for a new point-of-sale system for a chain of stores that ship packages around the universe. Perhaps a user representative tells you, “Then I select the state where I want to send the package from a drop-down list.” The phrase from a drop-down list indicates that this is a solution idea. The user is envisioning a specific type of user interface control. The prudent BA will ask, “Why from a drop-down list?” If the user replies, “That just seemed like a good way to do it,” then the real functional requirement is something like, “The system shall permit the user to specify the state where he wants to send the package.” This statement gives the developer a lot of flexibility in choosing the most appropriate interaction mechanism.
However, maybe the user says, “I suggested a drop-down list because we do the same thing in several other places and I want it to be consistent. Also, it prevents the user from entering invalid data, and I thought we might be able to reuse some code.” These are fine reasons to specify a specific solution. Recognize, though, that embedding a solution idea in a requirement imposes a design constraint on that requirement. It limits the requirement to being implemented in only one way. This isn’t necessarily wrong or bad; just make sure the constraint is there for a good reason.
The thrust of these two articles is that you can’t expect your customers to present a succinct, complete, and well-organized list of their needs. Instead, they will present you with a wide variety of inputs, all of which seem important to them, and it’s up to you—the BA—to sort through what you hear to phrase it in a useful way and park it in a sensible location. That’s a big part of what requirements analysis is all about.
Don’t forget to leave your comments below.
edible mushrooms in iowa
… [Trackback]
[…] Find More Information here to that Topic: batimes.com/articles/classifying-customer-input-part-2/ […]