November 24, 2014
Hot Topics:

Software Requirements Specifications: The Right Way

  • June 4, 2007
  • By Aleksey Shevchenko
  • Send Email »
  • More Articles »

Before you start getting into the how, let me talk about the why. Why do you need software requirements specifications (SRS)?

SRS are created to describe the functional and the non-functional requirements of what should be implemented in the system.The audience of software requirements specifications does not only consist of application developers, but of all the stakeholders—testers, project managers, users of the future system, and sponsors. SRS is a source of such deliverables as design specs, test cases, as well as budget and resource estimations. This is why it is so important that software requirements specifications are created in a way that is both complete and unambiguous. Once the SRS are published, any future changes to the document will create a ripple effect: The change created in the SRS will have to be reflected in all the documents that have been produced based on the SRS. This article will list eight guidelines that will help you create a well-written SRS that is both complete and unambiguous.

1. Use-Cases

Use-case is a term that comes from the object-oriented world. Use-case diagrams depict interactions between actors (users, systems, entities) and functions of a system. A use-case diagram helps you get a high-level view of the system. It is a great starting point before detailed specification requirements are created.

Take a look at the following use-case diagram that describes a use-case and actor interactions for an ATM machine.

The actors of the system are:

  1. User
  2. ATM Machine
  3. Bank

The functions (use-cases) of the system are:

  1. Login
  2. Get Balance Information
  3. Withdraw Cash
  4. Transfer Funds
  5. Deposit Cash

Notice that use-cases start with a verb.



Click here for a larger image.

The use-case diagram above reveals the following facts about this system:

  1. Identifies actors and functions of the system
  2. Identifies interactions between actors and features of the system
  3. Hints at the scope of the system

2. Use-Case Realization

Using use-case semantics for deriving functions of the system can greatly benefit you when composing the software requirements specifications (SRS). Use-cases are universally accepted in the software development community and they promote structure and completeness of the SRS.

Once a high-level use-case diagram is completed, a more detailed description of each use-case can start. The exercise of creating a more detailed use-case is also called a "Use-Case Realization." Each use-case contains a sequence of events (steps) that describe its execution flow. Furthermore, each use-case has a number of alternate paths, exceptions, pre-conditions, and post-conditions.

A common structure of a use-case realization consists of the following sections:

  1. Name: The name of the use-case
  2. Description: A brief explanation of what this use-case is achieving
  3. Actors: All participants of the use-case
  4. Pre-Conditions: All major events and states of the system that must be present before the use-case can be executed
  5. Post-Conditions: All major states that the system assumes after the use-case is executed
  6. Successful Path: All steps that fully describe successful execution of the use-case
  7. Paths: All steps that describe alternate execution of the use-case (If there are multiple alternate paths or alternate paths are lengthy, you might want to consider creating a separate use-case for it.)
  8. Exceptions: All errors that occur during execution of successful and alternate paths
  9. Rules: All business rules, computations, regulations, formulas, and constraints of the system

Try to create a simple use-case realization for a "Withdraw Cash" use-case:

  1. Name: Withdraw Cash
  2. Description: This use-case realizes cash withdrawal use case. First, the client requests cash. If there is enough cash in the client's account, the ATM disperses the specified amount and notifies the client of the new account balance and dispersed amount
  3. Actors: Client, ATM, Bank, System
  4. Pre-Conditions: Client is logged in
  5. Post-Conditions:
    1. Cash is dispersed
    2. Client's account balance is updated
    3. Client is notified of the transaction
  6. Successful Path:
    1. The client requests cash withdrawal
    2. The system establishes a connection with the Bank
    3. The system retrieves client's available account types
    4. The system displays available account types
    5. The client chooses a desired account type
    6. The client enters the amount to withdraw
    7. The system retrieves the selected account balance from the Bank
    8. The system validates available funds against account balance (see computation a in the Rules section below)
    9. The system prompts for confirmation
    10. The client confirms withdrawal amount
    11. The system computes new balance (see computation b in the Rules section below)
    12. The system disconnects from the Bank
    13. The system disperses specified amount
    14. The system prompts that cash is dispersed
    15. The system notifies the client of his transaction
  7. Alternate Paths: Start from step h in the successful path. The selected account type does not have sufficient funds:
    1. The system prompts the client that the withdrawal amount exceeds the account balance
    2. The system displays available account types
  8. Exceptions:
    1. No available account types: The system prompts that "No available account types exit"
    2. Requested amount exceeds account balance: The system prompts that "The requested amount exceeds account balance"
  9. Rules:
    1. Available funds computation: Withdrawal amount must be less than or equal to account balance
    2. New balance computation: Deduct withdrawal amount from account balance

Look at another use-case realization for the "Login" functionality:

  1. Name: Login
  2. Description: This use-case realizes the login function of the system. The client inserts a bank card into the ATM card slot and enters his password. If the password is correct, the system logs the client in.
  3. Actors: Client, ATM, Bank, System, Bank Card
  4. Pre-Conditions: None
  5. Post-Conditions: Client is logged in
  6. Successful Path:
    1. The client inserts his bank card into the ATM card slot
    2. The system validates the credit card
    3. The system prompts for the client's password
    4. The client enters the password
    5. The client confirms password entry
    6. The system validates the password
    7. The system logs the client into the system
  7. Alternate Paths: Start from Step 5 in the successful path
    1. The system validates the password and the password is incorrect
    2. The system increments invalid login count by 1
    3. The system notifies the client that the password is incorrect
    4. The system prompts for password
  8. Exceptions:
    1. Bank card is disabled
    2. Account is locked
    3. Bank card is reported stolen
    4. Password is incorrect
  9. Rules: Client account gets locked out after three unsuccessful login attempts.

In the above example, you have listed steps that actors perform to realize a use-case. Now, you can use these use-case realizations to start deriving more precise functional requirements.





Page 1 of 3



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel