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.<\/p>\n
Quality Attributes.<\/strong> 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<\/em> provides guidance on writing quality attributes.<\/p>\n You\u2019ve probably been asked to build user-friendly software, but I\u2019ll bet you\u2019ve 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, \u201cThe system shall be user-friendly\u201d or robust, or intuitive, or any of these other good things. Those are not useful requirements because we don\u2019t know just what they mean yet. But the customer has an important and legitimate idea behind each requirement, which you\u2019ll need to flesh out.<\/p>\n 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: \u201cWhat 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?\u201d As a BA, you\u2019ll 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.<\/p>\n External Interface Requirements.<\/strong> 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:<\/p>\n \u2022 \u201cMust read signals from (some device).\u201d<\/p>\n \u2022 \u201cMust send messages to (some other system).\u201d<\/p>\n \u2022 \u201cMust be able to read (or write) files in (some format).\u201d<\/p>\n \u2022 \u201cMust control (some piece of hardware).\u201d<\/p>\n \u2022 \u201cUser interface elements must conform to (some UI style standard).\u201d<\/p>\n Constraints.<\/strong> 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\u2019s 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?<\/p>\n 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.<\/p>\n The following are examples of constraints that you might hear from a customer:<\/p>\n Other phrases that suggest the speaker is describing a design or implementation constraint include these:<\/p>\n As with functional requirements, the analyst shouldn\u2019t simply transcribe the user\u2019s statement of a constraint into the SRS. Weak words such as identically<\/em> and consistent<\/em> 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.<\/p>\n Data Definitions.<\/strong> 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\u2019re presenting a data definition. \u201cThe ZIP code consists of five digits, followed by an optional hyphen and an optional four digits that default to 0000\u201d is a data definition. Collect these in a data dictionary, a master reference that the team can use throughout the product\u2019s development and maintenance. See Chapter 10 of Software Requirements, 2nd Edition<\/em> for more about data dictionaries.<\/p>\n 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?.<\/p>\n Solution Ideas.<\/strong> 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.<\/p>\n Suppose you\u2019re 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, \u201cThen I select the state where I want to send the package from a drop-down list.\u201d The phrase from a drop-down list<\/em> indicates that this is a solution idea. The user is envisioning a specific type of user interface control. The prudent BA will ask, \u201cWhy from a drop-down list?\u201d If the user replies, \u201cThat just seemed like a good way to do it,\u201d then the real functional requirement is something like, \u201cThe system shall permit the user to specify the state where he wants to send the package.\u201d This statement gives the developer a lot of flexibility in choosing the most appropriate interaction mechanism.<\/p>\n However, maybe the user says, \u201cI 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.\u201d 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\u2019t necessarily wrong or bad; just make sure the constraint is there for a good reason.<\/p>\n The thrust of these two articles is that you can\u2019t 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\u2019s up to you\u2014the BA\u2014to sort through what you hear to phrase it in a useful way and park it in a sensible location. That\u2019s a big part of what requirements analysis is all about.<\/p>\n Check out Software Requirements: Classifying Customer Input, Part 1<\/a>.<\/p>\n Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.\u00a0 Karl Wiegers is an independent consultant and not an employee of Jama. \u00a0He can be reached at\u00a0http:\/\/www.processimpact.com<\/a>.\u00a0 Enjoy these free\u00a0requirements management resources<\/a>.<\/em><\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[50],"tags":[51,60,61],"industry":[],"class_list":["post-3172","post","type-post","status-publish","format-standard","hentry","category-requirements-management","tag-business-requirements","tag-customer-needs","tag-use-cases"],"acf":[],"yoast_head":"\n\n
\n