Is there an analysis available that compares SRS to a use case approach to capture requirements?
This is a great question, because there is confusion regarding these two widely used formats, and I don't think I've ever seen such a comparison. There ought to be one; and my apologies if there already is one, but it probably wouldn't make some of the same points that I feel are important. So here goes.
Many organizations use one or the other, but not both, to capture requirements. However, some organizations do use both; and some authors say that use cases are derived from a software requirements specification (SRS), whereas other authors say just the opposite.
IEEE Standard 830-1998 provides a formal description of a software requirements specification, although my perception is that the term is used somewhat generically to describe a number of different though probably similar document formats that various organizations use for specifying software requirements.
An SRS provides a consistent structured format consisting of a number of separate sections for capturing a wide range of information about your requirements. The SRS starts with an introduction, which includes sections for purpose, scope, definitions, references, and an overview. Next the SRS has a general description, which includes sections describing product perspective, product functions, user characteristics, general constraints, and assumptions and dependencies. There may also be appendices and an index.
The heart of the SRS is the set of specific requirements. For each functional requirement ("The system shall…"), it is suggested to include an introduction plus sections describing inputs, processing, and outputs. Then come sections for external interface requirements, such as user interfaces, hardware interfaces, software interfaces, and communications interfaces.
Additional specific requirements sections address performance requirements, design constraints such as standards compliance and hardware limitations, attributes (often called "nonfunctional requirements," quality factors, or "ilities"), and other requirements such as database, operations, and site adaptation.
The strength of an SRS is that the extensively-identified set of topics makes sure important areas are addressed. However, many SRS users also cite this as a weakness, because it necessitates writing so much.
An SRS has two other less-frequently recognized but nonetheless very important weaknesses. Capturing each topic in a separate section, which I call "pigeon holing," is good in that it helps assure that all the topics are addressed, but its separation of related information can dramatically reduce meaning.
Pigeon holing's weakness is especially pronounced with respect to nonfunctional requirements, which is itself a misnomer based upon an inappropriate pigeon hole model. The term and the SRS's format imply that these quality factors exist in the abstract, that is, that you just need a bunch of usability, reliability, maintainability, and so forth. In fact, each is relevant only with regard to specific functionality; your usability requirements, for instance, may vary considerably with each function to which they pertain.
The other big weakness of an SRS is not the SRS itself, but rather stems from the likelihood that one's requirements definition is limited to the SRS. The SRS describes the requirements of a product/system/software that actually is high-level design of a presumed way how to accomplish the REAL business requirements deliverable whats the organization/users/customers/stakeholders need in order to provide value. Too often, the SRS capably describes an inappropriate product/system/software because the REAL business requirements it must satisfy have not been defined adequately, mainly because people think the SRS is the set of requirements.
"Use case" is a (horribly clumsy, in my humble opinion) term coined in Sweden by, I presume, non-native English speaker Ivar Jacobson, one of object orientation's "three amigos."
Use cases describe step-by-step how an actor interacts with the system, where an actor is usually the user, but could be another system or a piece of hardware. Many system designers, including me, used the same type of approach long before Jacobson popularized the term. Use cases often are considered part of object-oriented development, but they really are not limited to any particular methodology or even to information systems.
Each use case pertains to a specific business event, which is referred to as the "trigger." An example of a business event might be placing an order for some item. The use case describes from the perspective of the customer the set of steps that occur when the customer places the order, for instance:
The above set of steps is a scenario, one possible way of carrying out the use case. The most common scenario often is called the success scenario, main path, or happy path. Additional scenarios then are described to account for various alternatives and exceptions. For instance, scenario 2a might be for the situation where the system cannot find the customer.
Use cases can be hierarchical. For instance, step 7 above could have several subsidiary use cases describing each of the various ways the customer could pay for the order, such as credit card, check, cash, purchase order, or charging one's account. Some of those in turn could have subsidiary or alternative use cases, such as for when a credit card charge is authorized and when it is declined.
Similarly, one use case could refer to another use case. For example, step 2a where the customer was not found could invoke a separate use case for registering a customer. The Unified Modeling Language (UML) prescribes a use case diagram which shows the various use cases that may be involved and their interrelationships, with stick figures representing actors and ovals for use cases.
Use cases are a widely used and highly regarded format for capturing requirements. Because of their concrete step-by-step format, they are easy for a variety of stakeholders to understand in essentially the same way. Thus, use cases help developers create systems that act in the manner users expect.
A byproduct benefit of use cases is that they have inherent linkage to test cases. At a minimum, a use case is tested by carrying it out. Conventional wisdom, which is embodied in some use case definition tools, says that a use case can be tested thoroughly by having one test case for each scenario path. Unfortunately, most use cases overlook far too many of their possible paths and one usually needs many more than one test case to exercise the various likely ways that a given scenario in fact may be invoked.
While use case steps are fundamentally simple sentences as described in the above example, many organizations write steps that are much longer and more complex, which may improve understanding but often actually interferes with it. Regardless, one of the common limitations of use cases is that they don't include adequately detailed information to guide developers or testers as fully as needed.
Use cases describe behavior. The use case format is not well-suited to describe business rules or quality factors, which, of course, are two important forms of requirements. Some use case writers don't address business rules and quality factors at all, whereas others include them in separate pigeon hole sections referenced to the applicable steps, which can interfere with meaning.
A number of prominent requirements authorities state quite categorically that use cases are the user's requirements and the user's requirements are use cases. While the use case format can be describing user or business requirements (referred to as a business domain use case), in practice use cases almost always are system use cases which are really a form of design describing the usage requirements of the expected computer system.
To me, use cases describe the step-by-step usage behaviors for accomplishing a functional requirement/specification, which logically means developing some (preferably lightweight) form of an SRS before writing the use cases. However, some prominent authors suggest defining the use cases first and then deriving the functional requirements from the use cases.
Especially because use cases are often used in a quasi-religious manner ("How dare you question what I've come up with! I'm using use cases."), the existence of use cases virtually assures that they describe a design which has been created in the absence of adequately defined REAL business requirements that the designed system must satisfy to provide REAL value.
Both SRSs and use cases are valuable formats whose value is increased when their strengths and weaknesses are recognized and addressed in context.
06 Oct 2008