Download these IBM resources today! e-Kit: IBM Rational Systems Development Solution
With systems teams under so much pressure to develop products faster, reduce production costs, and react to changing business needs quickly, communication and collaboration seem to get lost. Now, theres a way to improve product quality and communication.
Webcast: Asset Reuse Strategies for Success--Innovate Don't Duplicate!
Searching for, identifying, updating, using and deploying software assets can be a difficult challenge. eKit: Rational Build Forge Express
Access valuable resources to help you increase staff productivity, compress development cycles and deliver better software, fast. Download: IBM Data Studio v1.1
Effectively design, develop, deploy and manage your data, databases, and database applications throughout the data management life. eKit: Rational Asset Manager
Learn how to do more with your reusable assets, learn how Rational Asset Manager tracks and audits your assets in order to utilize them for reuse.
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 use-case diagram above reveals the following facts about this system:
Identifies actors and functions of the system
Identifies interactions between actors and features of the system
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:
Name: The name of the use-case
Description: A brief explanation of what this use-case is achieving
Actors: All participants of the use-case
Pre-Conditions: All major events and states of the system that must be present before the use-case can be executed
Post-Conditions: All major states that the system assumes after the use-case is executed
Successful Path: All steps that fully describe successful execution of the use-case
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.)
Exceptions: All errors that occur during execution of successful and alternate paths
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:
Name: Withdraw Cash
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
Actors: Client, ATM, Bank, System
Pre-Conditions: Client is logged in
Post-Conditions:
Cash is dispersed
Client's account balance is updated
Client is notified of the transaction
Successful Path:
The client requests cash withdrawal
The system establishes a connection with the Bank
The system retrieves client's available account types
The system displays available account types
The client chooses a desired account type
The client enters the amount to withdraw
The system retrieves the selected account balance from the Bank
The system validates available funds against account balance (see computation a in the Rules section below)
The system prompts for confirmation
The client confirms withdrawal amount
The system computes new balance (see computation b in the Rules section below)
The system disconnects from the Bank
The system disperses specified amount
The system prompts that cash is dispersed
The system notifies the client of his transaction
Alternate Paths: Start from step h in the successful path. The selected account type does not have
sufficient funds:
The system prompts the client that the withdrawal amount exceeds the account balance
The system displays available account types
Exceptions:
No available account types: The system prompts that "No available account types exit"
Requested amount exceeds account balance: The system prompts that "The requested amount exceeds account balance"
Rules:
Available funds computation: Withdrawal amount must be less than or equal to account balance
New balance computation: Deduct withdrawal amount from account balance
Look at another use-case realization for the "Login" functionality:
Name: Login
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.
Actors: Client, ATM, Bank, System, Bank Card
Pre-Conditions: None
Post-Conditions: Client is logged in
Successful Path:
The client inserts his bank card into the ATM card slot
The system validates the credit card
The system prompts for the client's password
The client enters the password
The client confirms password entry
The system validates the password
The system logs the client into the system
Alternate Paths: Start from Step 5 in the successful path
The system validates the password and the password is incorrect
The system increments invalid login count by 1
The system notifies the client that the password is incorrect
The system prompts for password
Exceptions:
Bank card is disabled
Account is locked
Bank card is reported stolen
Password is incorrect
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.
Add www.developer.com to your favorites Add www.developer.com to your browser search box IE 7 | Firefox 2.0 | Firefox 1.5.xReceive news via our XML/RSS feed
IE 7
Firefox 2.0
