Ads
  

What Is a Software Requirement

What Is a Software Requirement

A software requirement is a capability that somebody needs or wants. It can be a component of an entire new application, a new feature for an existing application (an enhancement), or a request to correct a current shortcoming.

IEEE describes a requirement as: (a) a condition or capability needed by a user to solve a problem or achieve an objective; (b) a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document; (c) a documented representation of a condition or capability as in definition (a) or (b).

Types of Software Requirements

A requirement may be conscious (known, spoken) - something a stakeholder believes to be necessary. There are also "unconscious requirements" forgotten (unspoken) by the stakeholder because they aren't required right now, or they are unknown because they are required only by another stakeholder, or they are satisfied by some existing process, manual or automated. Weinberg and others suggest there are also "undreamed-of requirements" (unknown, unspoken) - those that the stakeholder doesn't know can be had. A conscious, forgotten, or unknown requirement may be functional or nonfunctional. Functional requirements specify what the software has to do. They are traceable to a specific source, often to use cases or business rules. They are often called "product features".

Nonfunctional requirements are mostly quality requirements that stipulate how well the software does what it has to do. Nonfunctional quality requirements that are especially important to users include specifications of desired performance, availability, reliability, usability, and flexibility. Nonfunctional quality requirements that are especially important to developers and maintainers include specifications of desired configurability and integratability of the software system, as well as maintainability, portability, and testability. Nonfunctional requirements may also be implicit requirements for changeability, reusability, and interoperability.

Some functional/nonfunctional requirements cannot be satisfied by one, or even a small set of, system components and are therefore dependent on other parts of the system. These require systemwide properties and a superset of quality requirements. Some requirements are architectural, such as component-naming compatibility, interfaceability, upgradability, and "system buildability". Other requirements are constraints, such as system design constraints, standards conformance, legal issues, and organizational issues. Constraints can come from users or organizations and may be functional or nonfunctional.

What Makes a "Good" Software Requirement?

In “Developing the Software Requirements Specification”, the translation of software requirements into software specifications is described. Here, during requirements elicitation, we are not so interested in formatting as we are in creating; the emphasis is on group activities designed to ensure that all requirements are considered, from every stakeholder's point of view. While we're gathering requirements, we can employ some simultaneous thoughts on what will make them viable software specifications - it never hurts to look ahead and make the next step a little easier.

There are attributes of quality that should permeate requirements. As we will see in “Software Quality Assurance” these "-ilities" that originated with McCall in the 1970s continue to be a significant guide for distinguishing "good" software requirements from those that are less than first-rate. Weigers points out that there are characteristics that individual requirement statements should exhibit, and desirable characteristics of the SRS document as a whole. We want to achieve both. According to Boehm, one of the most powerful tests for the "goodness" of a requirement is its testability. These experts suggest that if test cases can be written against a requirement, then it is unambiguous and measurable and, most importantly, we will be able to tell when it has been satisfied.

We can keep the following quality attributes in mind as we gather software requirements. Each requirement should be:

●  Correct - a quality that can only be ensured by the customer or user representative;
●  Possible (feasible) - a quality that requires knowledge of the environment on the part of the developer; available tools, techniques, people, and budgets must be able to satisfy the final requirements;
●  Necessary - a quality that can be determined between the developers and stakeholders in an interview or elicitation session; there are many features that are nice to have, but in the ranking of requirements for development and implementation of the first software version, "gold plating" is discouraged; one test for necessity is to trace the source of the requirement back to a use case scenario;
●  Prioritized - a quality that developers and stakeholders can determine; as we will explore in greater depth toward the end of this chapter, von Mayerhauser suggests three levels of priority: very important; absolutely necessary (to be implemented in the next release, essential); important, but not necessary for the next release (conditional); and purely optional (nice to have, but implementation will depend on resources and schedule);
●  Unambiguous - a quality that IEEE tells us means that there is only one interpretation; easy to read and understand;
●  Concise - with only the information necessary to proceed to the next development step; associated history, costs, schedule, and so on, are housed elsewhere;
●  Verifiable (testable, measureable) - a quality that means a person or machine can check that the software meets the requirement.

In addition to the quality of the individual requirement, we can pay attention to the future needs of the quality of the complete SRS:

●  Complete - a quality that can be ensured by stakeholder review and means that all significant requirements are included (functional, performance, external, etc.);
●  Consistent - a quality that the developers usually ensure and equals consistency among internal documents;
●  Changeable - requirements changes are a fact of life;
●  Traceable - a quality shared by stakeholder and developer that means the requirement can explicitly reference its source in an earlier document, such as that produced from a Joint Application Design (JAD) session; requirements should also be traceable forward to the SRS, then to design and code.

Gause and Weinberg remind us of the importance of clarity. They have an outstanding example of how a seemingly straightforward statement is prey to multiple interpretations. Taking a short familiar children's verse:

Mary had a little lamb

Its fleece was white as snow

And everywhere that Mary went,

The lamb was sure to go.

Here's how a different emphasis can result in a different meaning.

Mary had a little lamb, might lead us to believe that the point to the first line is that it is Mary's lamb in question, not Tom's, Dick's, or Harry's.

Mary had a little lamb, might lead us to believe that the point to the first line is that she no longer has the lamb.

Mary had a little lamb seems to indicate that Mary had only one lamb, not several.

Mary had a little lamb makes us wonder what other pets, that she didn't have, might have been an option - a dog, cat, cow, goat, parakeet?

Mary had a little lamb appears to emphasize that someone else (John?) still has his little lamb.

Mary had a little lamb could be meant to be contrasted with Pallas, who still has four large turtles.

Assume we take the definition of "had" to be "trick, fool"; the definition of "lamb" as "a person easily cheated or deceived esp. in trading securities"; "fleece" as "to strip of money or property by fraud or extortion"; and "snow" as "slang: to deceive, persuade, or charm glibly". Gause and Weinberg go on to say that the poem could be construed as being about

    …a charmingly glib but fraudulent person named Mary who tricked a small, helpless,
    gullible stock trader and stripped him of all worldly goods through deceit and
    extortion. Is it any wonder that
      Everywhere that Mary went,
      The lamb was sure to go.
      What else could the poor lamb do after she fleeced him?
      In short, the poem is making an editorial comment on today's business
    climate …

The frequently held view that the poem is about an innocent young lady with a loyal pet is naïve in the extreme - not as naive, though, as sophisticated adults who pick some line out of a requirements document and, without giving it a second thought, proceed to develop a product based on a single, wrong interpretation.


Tags

software requirement, product features, requirements elicitation
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
© Copyright 2018 SPMInfoBlog.
Designed by TechPlus