use cases Archives

Tag Archive for: use cases

Rather than expecting use cases to contain one hundred percent of the system’s functionality, I prefer to employ use cases to help the business analyst discover the functional requirements. That is, the use cases become a tool to reveal functionality rather than being an end requirements deliverable themselves. Users can review the use cases to validate whether a system that implemented the use cases would meet their needs. The BA can study each use case and derive the functional requirements the developer must implement to realize the use case in software. I like to store those functional requirements in a traditional SRS, although you could add them to the use case description if you prefer.

I’m often asked, “Which comes first: use cases or functional requirements?” The answer is use cases. Use cases represent requirements at a higher level of abstraction than do the detailed functional requirements. I like to focus initially on understanding the user’s goals so that we can see how they might use the product to achieve those goals. From that information, the BA can derive the necessary functionality that must be implemented so that the users can perform those use cases and achieve their goals. Conversely, if users present fragments of functionality during a requirements elicitation discussion, the BA should try to figure out which use case that functionality might with, if any.

Functional requirements—or hints about them—lurk in various parts of the use case. The remainder of this article describes a thought process a BA can go through to identify the less obvious functional requirements from the elements of a use case description.

Preconditions

Preconditions state conditions that must be true before the actor can perform the use case. The system must test whether each precondition is true. However, use case descriptions rarely state what the system should do if a precondition is not satisfied. The analyst needs to determine how best to handle these situations.

Suppose a precondition for one use case states, “The patron’s account must be set up for payroll deduction.” How does the system behave if the patron attempts to perform this use case but his account is not yet set up for payroll deduction? Should the system just notify the patron that he can’t proceed? Or should the system perhaps give the patron the opportunity to register for payroll deduction and then proceed with the use case? Someone has to answer these questions and the SRS is the place to provide the answers.

Postconditions

Postconditions describe outcomes that are true at the successful conclusion of the use case. The steps in the normal flow naturally lead to certain postconditions that indicate the user’s goal has been achieved. Other conditions, however, might not be visible to the user and therefore might not become a part of a user-centric use case description.

Consider an automated teller machine. After a cash withdrawal, the ATM software needs to update its record of the amount of cash remaining in the machine by subtracting the amount withdrawn. Perhaps if the cash remaining drops below a predetermined threshold the system is supposed to notify someone in the bank to reload the machine with additional money. I doubt any user will ever convey this information during a discussion of user requirements, yet the developer needs to know about this functionality.

How can you best communicate this knowledge to the developers and testers? There are two options. One is to leave the use case at the higher level of abstraction that represents the user’s view and have the requirements analyst derive the additional requirements through analysis. The BA can place those requirements in an SRS that is organized to best meet the developer’s needs. The second alternative is for the BA to include those additional details directly in the use case description. That behind-the-scenes information is not part of the user’s view of the system as a black box. Instead, you can think of that information as being white-box details about the internal workings of the use case that the analyst must convey to the developer.

Normal and Alternative Flows

The functionality needed to carry out the dialog between the actor and the system is usually straightforward. Simply reiterating these steps in the form of functional requirements doesn’t add knowledge, although it might help organize the information more usefully for the developer. The BA needs to look carefully at the normal flow and alternative flows to see if there’s any additional functionality that isn’t explicitly stated in the use case description. For example, under what conditions should the system offer the user the option to branch down an alternative flow path? Also, does the system need to do anything to reset itself so that it’s ready for the next transaction after the normal flow or an alternative flow is fully executed?

Exceptions

The BA needs to determine how the system could detect each exception and what it should do in each case. A recovery option might exist, such as asking the user to correct an erroneous data entry. If recovery isn’t possible, the system might need to restore itself to the state that existed prior to beginning the use case. The BA needs to identify the functionality associated with such recovery and restore activities and communicate that information to the developer.

Business Rules

Many use cases are influenced by business rules. The use case description should indicate which business rules pertain. It’s up to the BA to determine exactly what functionality the developer must implement to comply with each rule or to enforce it. These derived functional requirements should be recorded somewhere (I recommend documenting them in the SRS), rather than just expecting every developer to figure out the right way to comply with the pertinent business rules.

Special Requirements and Assumptions

The use case might assume that, for instance, the product’s connection to the Internet is working. But what if it’s not? The developer must implement some functionality to test for this error condition and handle it in an appropriate way.

In my experience, the process of having the BA examine a use case in this fashion to derive pertinent functional requirements adds considerable value to the requirements development process. There’s always more functionality hinted at in the use case than is obvious from simply reading it. Someone needs to discern this latent functionality. I would prefer to have an experienced BA do it rather than a developer.

Use Cases: A Pragmatic Approach

I recently spoke to a developer who said it was much more helpful to receive requirements information organized in a structured way from the BA than to have to figure out those details on his own. This developer preferred to rely on the BA’s greater experience with understanding the problem domain and deriving the pertinent functional requirements. Not only did this result in better requirements, but it also allowed the developer to focus his talents and energy where he added the most value, in designing and coding the software.

My philosophy of employing use cases as a tool to help me discover functional requirements means that I don’t feel a need to force every bit of functionality into a use case. It also gives me the option of writing use cases at whatever level of detail is appropriate. I might write some use cases in considerable detail to elaborate all their alternative flows, exceptions, and special requirements. I could leave other use cases at a high level, containing just enough information for me to deduce the pertinent functional requirements on my own. The functional requirements are the end result of requirements analysis, regardless of where you choose to store them or whether you even write them down at all. Developers don’t implement use cases: they implement specific fragments of functional behavior that allow users to accomplish valuable tasks with the software.

Deriving functional requirements from the use case always takes place on the journey from ideas to executable software. The question is simply a matter of who you want to have doing that derivation and when. If you deliver only use cases without all the functional detail to developers, each developer must derive the additional functionality on his own. It’s also unlikely that all developers will record the functional requirements they identify. This makes it hard for testers to know exactly what they need to test. It also increases the chance that someone will inadvertently fail to implement certain necessary functionality. If you’re outsourcing construction of the software, you can’t expect the vendor’s developers to accurately determine the unstated functionality from a use case description.

You will almost always have additional functional requirements that do not fit nicely into a particular use case. Earlier in this article, I mentioned the example of logging in to a system. Clearly, that functionality must be implemented, but I don’t consider it to be a use case. You might also have functional requirements that span multiple use cases. Consider the behavior the system should exhibit if a required Internet connection goes down. The Internet connection could fail while the user is executing any use case. Therefore, this error condition doesn’t constitute an exception flow associated with a specific use case. It needs to be detected and handled in multiple operations. The BA can place all the functional requirements that are not associated with or derived from a particular use case into the logically appropriate section of the SRS.

I have found use cases to be a highly valuable technique for exploring requirements on many types of projects. But I also value the structured SRS as an effective place to adequately document the functional requirements. Keep in mind that these documents are simply containers for different types of requirements information. You can just as readily store use cases, functional requirements, and other types of requirements information in the database of a requirements management tool or in other forms. Just don’t expect use cases to replace all your other strategies for discovering and documenting software requirements.

Read When Use Cases Aren’t Enough, Part 1.

Read When Use Cases Aren’t Enough, Part 2.

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. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.

I once read a book about use cases that stated, “To sum up, all functional requirements can be captured as use cases, and many of the nonfunctional requirements can be associated with use cases.” I agree with the second part of this sentence, but not with the first part. It is certainly true that use cases are a powerful technique for discovering the functional requirements for a system being developed. However, this statement suggests that use cases are the only tool needed for representing a software system’s functionality. In most cases, they aren’t.

Use Cases Don’t Replace Functional Requirements

This notion that all functional requirements can fit into a set of use cases and that use cases contain all the functional requirements for a system appears in many of the books and methodologies that deal with use cases. The thinking seems to be that the use cases are the functional requirements. If the BA writes good use cases, the developers are supposed to be able to build the system from that information, along with additional nonfunctional requirements information that’s included in a supplementary specification. Nonfunctional requirements, such as performance, usability, security, and availability goals, typically relate to a specific use case or even to a particular flow within a use case.

After querying the thousands of students I’ve taught in requirements seminars over the years, I have met just a single person who has found this pure use case approach to work! On the contrary, dozens of BAs have told me, “We gave our use cases to the developers and they got the general idea, but the use cases just didn’t contain enough information. The developers had to ask a lot of questions to get the additional requirements that weren’t in the use cases.” I suppose you could argue that they must not have been very good use cases. But when dozens of people report the same unsatisfactory experience when trying to apply a particular methodology, I question the methodology’s practicality.

There are three problems with adhering to this philosophy of use case purity. First, your use cases must contain all the functional detail that the analysts need to convey to the developers. That requires writing highly detailed use cases. The sample use cases in some books do include some complex examples. But elaborate use cases become hard to read, review, and understand.

The second problem with this approach is that it forces you to invent use cases to hold all the functional requirements because a use case is the only container you have available to describe system functionality. However, some system functionality does not fit appropriately into a use case. I have seen many new use case practitioners struggle to create inappropriate use cases to hold all the bits of functionality, to no useful end.

Logging in to an ATM or a Web site is an example that illustrates this problem. In their book Use Case Modeling (Addison Wesley, 2003) Kurt Bittner and Ian Spence provide this good definition of a use case:

Describes how an actor uses a system to achieve a goal and what the system does for the actor to achieve that goal. It tells the story of how the system and its actors collaborate to deliver something of value for at least one of the actors.

By this definition, logging in to a system is not a legitimate use case because it provides no value to the person who is logging in! No one logs in to a system and feels as though he accomplished something as a result. Logging in is a means to an end, a necessary step to being able to perform use cases that do provide value. Nevertheless, the functionality to permit login and everything associated with it (such as business rules or integrity requirements regarding passwords) must be defined somewhere. If you’re using only use cases as a container for functional requirements, you wind up being forced to invent artificial use cases—those that don’t provide user value—just to have a place to store certain chunks of functionality. This artificiality does not add value to the requirements development process.

Use Cases and an SRS Organize Information Differently

A third shortcoming of the use case–only philosophy is that use cases are organized in a way that makes good sense to users but not necessarily to developers. As Figure 1 illustrates, a use case consists of multiple small packages of information. A typical use case template contains sections for preconditions, postconditions, the normal flow of events, zero or more alternative flows (labeled with Alt. in Figure 1), zero or more exceptions (labeled with Ex.), possibly some business rules, and perhaps some additional special requirements.

Figure 1. Use case organization (left) differs from SRS organization (right).

These small packages are easy to understand and review, but they make it hard for the developer to see how the pieces fit together. As a developer myself, I find it more informative to see all the related requirements grouped together in a logical sequence. Suppose I read a functional requirement that implements a step in the normal flow. I want to see the requirements dealing with branch points into alternative flows and conditions that could trigger exceptions immediately following that one functional requirement. I’d like to see the requirements that handle each business rule in context, juxtaposed with the relevant system functionality. This is easier than having to figure out just what bits of the use case the business rule affects on my own.

As Figure 1 illustrates, the functional requirements that come from the various chunks of a use case can be sprinkled throughout a hierarchically organized SRS. Traceability analysis becomes important so that you can make sure every functional requirement associated with the use case traces back to a specific part of the use case. You also want to ensure that every piece of information in the use case leads to the necessary functionality in the SRS. In short, the way a use case is organized is different from the way many developers prefer to work.

It gets even more confusing if you’re employing use cases to describe the bulk of the functionality but have placed additional functional requirements that don’t relate to specific use cases into a supplemental specification. This approach forces the developer to get some information from the use case documentation and then to scour the supplemental specification for other relevant inputs. Before your analysts impose a particular requirements-packaging strategy on the developers, have these two groups work together to determine the most effective ways to communicate requirements information.

My preference is for the analyst to create an SRS as the ultimate deliverable for the developers and testers. This SRS should contain all the known functional and nonfunctional requirements, regardless of whether they came from use cases or other sources. Functional requirements that originated in use cases should be traced back to those use cases so that readers and analysts know where they came from.

In the final article of this three-part series, I’ll describe the thought process I go through when deriving functional requirements from the various elements of a use case.

Read the When Use Cases Aren’t Enough, Part 1.

Read the When Use Cases Aren’t Enough, Part 3.

Use cases are recognized as a powerful technique for exploring user requirements. The great benefit they provide is to bring a user-centric and usage-centric perspective to requirements elicitation discussions. The business analyst employs use cases to understand what the user is trying to accomplish and how he envisions his interactions with the product leading to the intended user value. Putting the user at the center is much better than focusing on product features, menus, screens, and functions that characterize traditional requirements discussions. And the structure that use cases provide is far superior to the nearly worthless technique of asking users “What do you want?” or “What are your requirements?”

As with most new software development techniques, use cases have acquired a bit of a mystique, some misconceptions, overblown hype, and polarized camps of enthusiasts who will all try to teach you the One True Use Case Way. In this series of three articles (adapted from my book More about Software Requirements), I share my perspectives on when use cases work well, when they don’t, and what to do when use cases aren’t a sufficient solution to the requirements problem.

The Power of Use Cases

I’m a strong believer in the use case approach. Users can relate to and review use cases because the BA writes them from the user’s point of view, describing aspects of the user’s business. In my experience, once they get past the discomfort of trying a new technique, users readily accept the use case method as a way to explore requirements.

I’m often asked how to write requirements specifications so that users can read and understand them and also so that they contain all the detail that developers need. In many cases, one requirements representation won’t meet both of these objectives. Users can comprehend use cases, but they might balk at reviewing a more detailed mass of functional requirements. Use cases give developers an overall understanding of the system’s behavior that fragments of individual functionality cannot. However, developers usually need considerably more information than use cases provide so that they know just what to build. In many circumstances, the combination of employing use cases to represent user requirements and a software requirements specification to contain functional and nonfunctional requirements meets both sets of needs.

Project Type Limitations

My experience has shown that use cases are an effective technique for many, but not all, types of projects. Use cases focus on the user’s interactions with the system to achieve a valuable outcome. Therefore, use cases work well for interactive end-user applications, including Web sites. They’re also useful for kiosks and other types of devices with which users interact.

However, use cases are less valuable for projects involving data warehouses, batch processes, hardware devices with embedded control software, and computationally intensive applications. In these sorts of systems, the deep complexity doesn’t lie in the user–system interactions. It might be worthwhile to identify use cases for such a product, but use case analysis will fall short as a technique for defining all the system’s behavior.

As an illustration, I once worked on a computational program that modeled the behavior of a multi-stage photographic system. This software used a Monte Carlo statistical simulation to perform many complex calculations and it presented the results graphically to the user. The user-system dialog needed to set up each simulation run was quite simple. The complexity resided behind the scenes, in the computational algorithms used and the reporting of results. Use cases aren’t very helpful for eliciting the requirements for these aspects of a system.

Use cases also have limitations for systems that involve complex business rules to make decisions or perform calculations. Consider an airline flight reservation system, one of the classic examples used to illustrate use cases. Use cases are a fine technique for exploring the interactions between the traveler and the reservation system to describe the intended journey and the parameters associated with it. But when it comes to calculating the fare for a specific flight itinerary, a use case discussion won’t help. Such calculations are driven by the interaction of highly complex algorithms and rules, not by how the user imagines conversing with the system.

Nor are use cases the best technique for understanding certain real-time systems that involve both hardware and software components. Think about a complex highway intersection. It includes sensors in the road to detect cars, traffic signals, buttons pedestrians can press to cross the street, pedestrian walk signals, and so forth. Use cases don’t make much sense for specifying a system of this nature. Here are some possible use cases for a highway intersection:

A driver wants to go through the intersection.
A driver wants to turn left when coming from a particular direction.
A pedestrian wants to cross one of the streets.

These are use cases in the sense that they describe a goal a user is trying to achieve with the system, but they aren’t terribly useful in terms of illuminating the necessary system functionality. Exploring the interactions between these actors (drivers and pedestrians) and the intersection-control software system just scratches the surface of what’s happening with the intersection. The use cases don’t provide nearly enough information for the analyst to define the functionality for the intersection-control software.

Use cases aren’t particularly helpful for specifying the requirements for batch processes or time-triggered functions, either. My library’s information system automatically sends me an e-mail to remind me when an item I’ve borrowed is due back soon. This e-mail is generated by a scheduled process that checks the status of borrowed items overnight (the one I received today was sent at 1:06 AM) and sends out notifications. Some analysts regard “time” to be an actor so that they can structure this system behavior into a use case. I don’t find that helpful, though. If you know the system needs to perform a time-triggered function, just write the functional requirements for that function, instead of packaging it into a contrived use case.

Event-Response Tables

A more effective technique for identifying requirements for certain types of applications, such as real-time systems, is to consider the external events the system must detect. Depending on the state of the system at the time it detects a given event, the system produces a particular response. Event-response tables are a convenient way to collect this information.

Events could be signals received from sensors (signal events), time-based triggers such as scheduled program executions (temporal events), or user actions that cause the system to respond in some way (business events). In fact, the trigger that initiates a use case is sometimes termed a business event.

The highway intersection system described earlier has to deal with various events, including these:

A sensor detects a car approaching in one of the through lanes.
A sensor detects a car approaching in a left-turn lane.
A pedestrian presses a button to request to cross a street.
One of many timers counts down to zero.

Exactly what happens in response to an external event depends on the state of the system at the time it detects the event. The system might initiate a timer to prepare to change a light from green to amber and then to red. The system might activate a Walk sign for a pedestrian (if the sign currently reads Don’t Walk), or change it to a flashing Don’t Walk (if the sign currently says Walk), or change it to a solid Don’t Walk (if it’s currently flashing). The BA needs to write the functional requirements to specify both how to detect the events and the decision logic to use when combining events with states to produce system behaviors.

Table 1 presents a fragment of what an event-response table might look like for such a system. Each expected system behavior consists of a combination of event, system state, and response. State-transition diagrams and statechart diagrams are other ways to represent this information visually, but at a higher level of abstraction. Use cases just aren’t enormously helpful in this situation.

Table 1. Partial Event-Response Table for a Highway Intersection

Event	System State	Response
Road sensor detects vehicle entering left-turn lane.	Left-turn signal is red. Cross-traffic signal is green.	Start green-to-amber countdown timer for cross-traffic signal.
Green-to-amber countdown timer reaches zero.	Cross-traffic signal is green.	Turn cross-traffic signal amber. Start amber-to-red countdown timer.
Amber-to-red countdown timer reaches zero.	Cross-traffic signal is amber.	Turn cross-traffic signal red. Wait 1 second. Turn left-turn signal green. Start left-turn-signal countdown timer.
Pedestrian presses a specific walk-request button.	Pedestrian sign is solid Don’t Walk. Walk-request countdown timer is not activated.	Start walk-request countdown timer.
Pedestrian presses walk-request button.	Pedestrian sign is solid Don’t Walk. Walk-request countdown timer is activated.	Do nothing.
Walk-request countdown timer reaches zero plus the amber display time.	Traffic signal in walk direction is green.	Change all green traffic signals to amber.
Walk-request countdown timer reaches zero.	Traffic signal in walk direction is amber.	Change all amber traffic signals to red. Wait 1 second. Set pedestrian sign to Walk. Start don’t-walk countdown timer.

Defining the requirements for this complex system of interacting hardware and software components demands more than use cases. Most of the system’s complexity lies not in the user interactions but under the hood. An event-response approach will go much farther toward understanding the requirements for such a system.

Check out When Use Cases Aren’t Enough, Part 2.

Check out When Use Cases Aren’t Enough, Part 3.

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 flesh 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 (some device).”

• “Must send messages to (some other system).”

• “Must be able to read (or write) files in (some format).”

• “Must control (some piece of hardware).”

• “User interface elements must conform to (some UI style standard).”

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 (a specific programming language).”
“Can’t require more than (some amount of memory).”
“Must operate identically to (or be consistent with) (some other system).”
“Must use (a specific user interface control).”

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.

Check out Software Requirements: Classifying Customer Input, Part 1.