Home

Software process improvement

Agile software development

JAD and RAD

System requirements

System functional specification

System requirements.

Requirements definition

A requirement is a statement (or series of statements) that document a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user. In its most essential definition the requirements can be applied to a:-

  • Process
  • Process component

    In the commercial world the process is a business process and the process component requirements would be system components that contribute to the overall business process requirements. Consider the Sales order process, this would contain process components (computer based) for calculating tax, goods availability etc. as well as manual processes for picking and packing the goods. Both the complete process and process components would have requirements associated with them.

    Requirements scope

    Most people working in software would view requirements as pertaining to a software component, i.e. software requirements. When a separate technology group exists to provide software based on a requirements specification then the software requirement becomes the specification and the measure of the software quality becomes meeting the specification.

    When a company has a processing capability that includes manual and systems solutions (which is the vast majority of cases) then the term system applies to the total processes, including manual. In this case the term System's requirements applies to what capabilities and attributes are required from the whole set of processes that produce a service or product.

    By way of example consider a Sales order processing system. In the wider definition of system, a sales order processor may receive a FAX for an order, they may then place the order in a basket sorted by date. The order could then be typed into a computer system for calculation of price, tax etc. From this simple example it is clear that the overall processing of an order involves both manual and systems processing. It is also clear that the two (manual and computer) are inseparable and have an interdependent relationship.

    The computer systems requirement, in the sales order example, would be a subset of the overall sales order processing requirements. It would be useful to have one set of requirements for the complete sales process and then break out the requirements that are satisfied by automation (i.e. tax calculation etc.). In this way the overall purpose of the systems does not have a life of its own but rather can be traced, and seen supporting, the overall requirements or goals of the wider processes.

    Whenever requirements are being produced it is very important that the scope of the requirements is known and if the scope is narrow (to a component or piece of software) it is important that the relationship this component has with the wider processing requirements is also documented. In this way the reason for the existence of the software is recorded so that if these reasons change then the software changes in synch with the wider requirements.

    How are requirements specified?

    Regardless of the scope of the requirements the specification of the requirement is typically a statement of a capability or constraint. The term constraint is sometimes referred to as a non-functional requirement. For example a non-functional requirement may pertain to throughput, so that a requirement statement of:-

  • The system should be able to accept 200 new sales orders an hour
  • The system should take one hour to either allocate the goods or place an order for the goods not allocated.

    In the above requirements it is not important what the scope of the system is, in that it could be the computer system or the whole manual and computer processes. What is important is that these types of requirements do not relate to how the orders are processed but rather to how fast the orders are processed. Now consider the following requirements:-

  • For CA state internet orders an 8% state tax should be added.
  • All non CA orders should have no state tax added.

    The above two requirements are functional requirements and describe what functionality of the system is required.

    In practice there are many notations for describing the functional and non-functional requirements. Structured English is one of the more useful and this should be done using objects (i.e. nouns) from a single data dictionary.

    What versus How

    For all requirements, regardless of scope, the requirement should be defined in terms of What is required and not how the requirements should be satisfied. The implementation of the requirement into the system is the responsibility of system's designers. The more scope the systems designers have, to satisfy the given requirement, the greater number of options will be available for consideration. If the requirements contain how something should be implemented then the design moves into the requirement and there are good reasons to keep the design and the requirement separate. The main reason for separating requirements from design, or the what from the how, is that if the essential requirement changes the design can be changed accordingly. If the requirement is embedded in the design then it is difficult to see the wood from the trees and the essential value or purpose of the system is lost.

    Conclusions

    A requirement is a statement of capability of a given system. The system can have a wider scope, to include manual process. The requirement can be functional or non-functional. Whether functional or non-functional, and regardless of scope, it is preferable to separate the requirement from the solution. The requirement should specify what is required while the design should specify how this is achieved.

    No guarantee (or claim) is made regarding the accuracy of this information. Any questions or comments should be sent to:-