Artifacts >
Requirements Artifact Set >
{More Requirements Artifacts} >
Software Requirements Specification >
Guidelines
Artifacts >
Requirements Artifact Set >
{More Requirements Artifacts} >
Software Requirements Specification >
Guidelines
Guidelines:
|
 Software Requirements Specification |
The Software Requirements Specification (SRS) captures the complete software requirements for the system, or a portion of the system. |
This information partially derived from content provided by IBM Corporation. 
The Software Requirements Specification (SRS) focuses on the collection and organization of all requirements surrounding your project. Refer to the Requirements Management Plan to determine the correct location and organization of the requirements. For example, it may be desired to have a separate SRS to describe the complete software requirements for each feature in a particular release of the product. This may include several use cases from the system use-case model, to describe the functional requirements of this feature, along with the relevant set of detailed requirements in Supplementary Specifications.
Since you might find yourself with several different tools for collecting these requirements, it is important to realize that the collection of requirements may be found in several different artifacts and tools. For example, you might find it appropriate to collect textual requirements such as non-functional requirements, Design Constraints, etc, with a text documenting tool in Supplementary Specifications. On the other hand, you might find it useful to collect some (or all) of the functional requirements in the use cases and you might find it handy to use a tool appropriate to the needs of defining the use-case model.
We find that there is no strong reason to focus on the differences between the tools used. After all, you are collecting requirements and you really should focus on the efficient collection and organization of the requirements without regard to the tools at hand. Since we are focused on the requirements and not on the tools, we will assume that the collection of requirements in the SRS constitutes a package of information. The elaboration of the various requirements for the system is embodied in a package we call the Software Requirements Specification (SRS).
The SRS Package is obviously related to the Vision document. Indeed, the Vision document serves as the input to the SRS. But the two artifacts serve different needs and are typically written by different authors. At this stage in the project, the focus of the project moves from the broad statement of user needs, goals and objectives, target markets and features of the system to the details of how these features are going to be implemented in the solution.
What we need now is a collection, or package, of artifacts that describes the complete external behavior of the system - i.e., a package that says specifically, “Here is what the system has to do to deliver those features.” That is what we refer to as the SRS Package.
The SRS Package is not a frozen tome, produced to ensure ISO 9000 compliance and then buried in a corner and ignored as the project continues. Instead, it is an active, living artifact. Indeed it has a number of uses as the developers embark upon their implementation effort: It serves as a basis of communication between all parties - i.e., between the developers themselves, and between the developers and the external groups (users and other stakeholders) with whom they must communicate. Formally or informally, it represents a contractual agreement between the various parties - if it’s not in the SRS Package, the developers shouldn’t be working on it. And if it is in the SRS Package, then they are accountable to deliver that functionality.
The SRS serves as the project manager’s reference standard. The project manager is unlikely to have the time, energy, or skills to read the code being generated by the developers and compare that directly to the Vision document. He or she must use the SRS Package as the standard reference for discussions with the project team.
As noted earlier, it serves as input to the design and implementation groups. Depending on how the project is organized, the implementers may have been involved in the earlier problem-solving and feature-definition activities that ultimately produced the Vision document. But it’s the SRS Package they need to focus on for deciding what their code must do. It serves as input to the software testing and QA groups. These groups should also have been involved in some of the earlier discussions, and it’s obviously helpful for them to have a good understanding of the “vision” laid out in the Vision documents. But their charter is to create test cases and QA procedures to ensure that the developed system does indeed fulfill the requirements laid out in the SRS Package. The SRS Package also serves as the standard reference for their planning and testing activities.
See Guidelines: Use-Case Model and Guidelines: Use Case for a full discussion of the recommended approach to defining functional requirements within a Use-Case Model and the Use Cases.
The non-functional requirements of your system should be documented in the Artifact: Supplementary Specifications. Following are guidelines to follow when defining these requirements.
While gathering and validating non-functional requirements, maintain Assumptions and Issues lists.
Some activities will not give you satisfactory answers. This can be due to lack of information, or simply because you consider the answer threatens the viability of the design. Therefore, create two lists, and maintain them through the design study:
Any assumptions you make during the requirements and design process, including the rationale or thought processes behind those assumptions. Assumptions may be used to identify related subprojects or items of work which are outside the scope of or after this project.
Any major issues (significant concerns that could become show-stoppers)
The issues should be reviewed with the customer at the and of each phase. The assumptions need to be reviewed also, at the end of each phase, but the customer might not always be the correct person for the less important ones.
Assumptions and issues apply to all artifacts, but are particularly common for non-functional requirements.
Document the client’s geographic organization.
Document the geographic locations of the part of the business affected by this system. The definition should include those unaffected sites also, which host major IT facilities. Make special note of any part of the organization that is mobile. For instance a sales force that will travel about and use workstations. Note any geographic locations at which you may have to provide special natural language support (NLS).
Do the requirements specify the use of any application packages? One very important "given" that may dictate strongly some of the system design decisions is the use of a specific application package that provides predefined software logic and data organization. Some software packages are flexible and allow a great deal of customization; some are very rigid and do not. Packages may dictate such components and decisions as:
It is important to understand what influences any given package will have upon your design. If you have a "given" package, make sure you have the right skills and knowledge about this package available to you. This might come from:
Do not assume that this knowledge is readily available. Ensure that it will be available to you when you need it.
Document any other givens in the requirements that will limit the flexibility of your design.
This is to catch any specific requirements not explicitly covered in earlier activities that might limit the flexibility of your design. For example, look for:
Will any of these givens affect the new system? If the new system is to run on an existing processor, operating system image, or network configuration, are the characteristics of the existing platform and workload going to affect the new system?
How much connection and processing capacity is already taken by existing workloads?
What security controls are used by existing workloads? Note these, and check them against the security requirements of the new system when you consider the latter.
What are the availability characteristics of the existing workload?
Note anything which might affect your later design of availability for the new system. For example, does the existing workload insist on shutting down the whole of a processor each night?
Do the requirements specify the use of any special hardware?
This might be stated in generic terms ("the system must support a high-speed flat-bed plotter") or be more specific ("the existing Panda Corp ATMs will be supported"). Document, as far as you can:
Do the requirements specify the use of existing data? If so, then this will influence your system design. Document:
Does the client have a technical architecture and/or IT strategic plan (or equivalent set of standards)?
A technical architecture is roughly equivalent to the following:
In a technical architecture you might find some of the following defined for you:
· Directory and naming services that keep track of network resources and attributes
· Security services that protect network resources from unauthorized used by registering users and their authorization levels
· Time services that regulate date and time across the network
· Transaction management services that coordinate resource recovery across various systems in a network
· Hardware
· System control software
· Broad application software such as "Office"
· Help desk use
· Security rules
The list may be very extensive and the items in it may be policed on a very rigid basis or may not be enforced at all.
Document any requirements that specifically ask for, or exclude, the use of sub-architectures such as:
Special architectures that may be implied by the use of a packaged application solution. Remember some application packages are architectural definitions in their own right.
Document the degree of openness (that is, vendor independence and interoperability) required by the client. If there is a technical architecture, then your design will almost certainly have to comply with it. You should read it and understand the rules that will influence design of this system.
Does the client have a network architecture to which this system must conform? A network architecture is a common set of rules for high-level connectivity, plus a common transport infrastructure. This might include the definition of a backbone network, including concentrators and lines. If there is such an architecture, then understand the essential rules and topology and document:
Considerations for physical topology (that is, whether the network is essentially rural or metropolitan and whether the network attachment are densely populated versus loosely distributed).
What high-level connection functions are supported by the current network infrastructure.
What communications standards are used (for example SNA, OSI, TCP/IP) to support these connections functions.
What programming interfaces are supported.
Any network architecture definitions of the connectivity between client/server layers or the base system model layers like:
Does the client have any stated policies for connections?
Even if you don’t have technical or network architectures, you may still have some connection policies.
Document any policies regarding:
Does the client have any other policies, standards or rules not explicitly stated in their requirements? For example:
If there are other policies, then make sure you understand them and have access to them so that you can ensure that your design conforms to the standards in the later phases of the design process. The use of a packaged application solution may well bring with it some implied standards.
What is the policy on allowing users or departments to add and/or develop their own local programs on:
Without controls, you may find that local usage quickly uses up resources which are needed by the production systems for which the local components were originally bought. You may find that you cannot install the production system by the time it is finally ready for rollout.
Work with the applications development personnel to break down the business processes into more granular units such as smaller business processes or transactions.
The reason for doing this is that you are going to capture numbers in the next question, and you have to decide what it is you are going to count.
Be aware that a business process may start several instances of smaller business transactions (for example multiple item orders per customer order) and these multipliers should be remembered when you document the numbers. However, do not get caught up with too much detail, particularly for a complex system.
A business "process" (for example, "customer order handling") will typically be implemented by an "application" (an IT term), or may span more than one application. Within each application, there will usually be many IT "transactions", for example, "query stock level" or "generate customer letter".
Different communities use their own names to identify the units we are trying to agree. For example, "transaction" might mean one thing to people with an applications development background, and a completely different thing to the infrastructure team. It is important to work together to correlate the names and then collect the information.
Identify and document volume and sizing information for each of the units in 4.1: "Units of measurement", for example:
The client may have performance criteria specified for some or all the business processes. However, remember also to document performance targets for system support processes (such as system backup) and applications development processes if identified. For each category, document:
The recommended approach to establishing availability requirements is as follows:
Consider these guidelines as you form the availability requirements:
Some examples:
For each of the business processes and the groups of users who must perform them, identify the hours during which the user must be able to perform that process. Remember also to do this for those processes which are not directly associated with user group(s).
If there are user groups in different time zones (such as the earlier New York / Hong Kong example), treat them as separate groups of users.
Also show if there will be occasional periods, such as business holidays, when the application may not be needed. (This gives the designer the flexibility to use those periods for extended maintenance). What changes are anticipated in these service hours over the projected life of the application?
The service hours of this system may also be affected by those of other systems with which this one interfaces.
How are the scheduled service hours of this system expected to change over its projected life?
Understand the BUSINESS IMPACT, FINANCIAL COSTS, AND RISKS associated with service interruptions during the scheduled service hours.
To identify what availability requirements are really important for this system, consider the set of business processes and groups of users and identify the business impact that would result from:
When assessing the impact of each outage, identify fallback procedures and consider how they can reduce the true business impact of the outage.
Try to quantify this impact in financial terms (cost of lost staff or equipment productivity, value of lost current business, estimated loss of future business due to customer dissatisfaction, interest expenses, regulatory penalties, etc.).
Provide as many answers as necessary to reflect differences in the costs and risks associated with outages of different duration’s, at different times of the day, whether planned or unplanned, which business processes or users are affected, etc.
How is the business/financial impact of a service interruption anticipated to change during the projected life of this system?
Review each of these agreed important business processes to identify alternatives to allow the most critical elements of those processes to proceed should some portions of the system become temporarily unavailable. The ability to operate temporarily with reduced business function may be a way to help reduce the availability impact of interdependencies among critical processes and data.
Some examples:
Remember that when the system is working with reduced function there may be a limit to which this is acceptable to the business processes. For example, an out-of-date customer balance must not be more than 24 hours out-of-date.
If service is interrupted during the scheduled hours (see "Scheduled service hours") the impact of the interruption will usually vary depending on outage duration and other conditions. Some outages may have minimal impact on the users’ ability to perform their business processes (brief outages, those which occur during lightly-used periods of the day, those which impact only a subset of the user group, or those for which an acceptable manual fallback procedure exists). Other outages, such as those which are longer or occur during a "critical" period of the day, may have a more significant impact.
Some examples:
Identify the AVAILABILITY AND RECOVERY CRITERIA that would apply under "normal" situations.
Exclude "disaster" situations, such as an extended loss or shutdown of the entire computing facility.
Based on the business/financial costs and risks identified in "Service outage costs", develop a specification of the availability criteria that must be met to avoid significantly inhibiting user groups from performing their assigned business processes. Such criteria might be specified in forms such as:
Be as specific as necessary to reflect factors such as differences between planned and unplanned outages, the hour during which the outage occurs (for example "critical" periods versus lightly used periods) whether all users or only a few are affected, etc.
Be careful not to specify unnecessarily stringent availability criteria, as this could significantly affect the implementation cost. In general, if significant business/financial costs or risks cannot be identified with a given set of outage conditions, this may be an indication that this set of outage conditions should not be included in the stated availability criteria.
If "Scheduled service hours" suggested that the scheduled service hours are likely to change, and/or "Service outage costs" suggested that the business/financial costs or risks associated with a service interruption are likely to change during the projected life of the system, estimate how the availability criteria would change as a result.
If cryptography is to be used, there will be additional recovery and availability considerations. For example:
Is disaster recovery required within the scope of this design project (availability during "disaster" situations, such as extended loss or shutdown of the entire computing facility)? If so, what are the criteria for such recovery?
Be aware that probably not all business processes will require disaster recovery facilities. Select only those processes that are critical and do require disaster recovery. Even within those processes, not all functions may need to be covered.
Note that there may be different sets of criteria for different parts of the system or depending on the type of disaster.
What changes in the above disaster recovery requirements are anticipated during the projected life of the application?
To design a system that recovers as quickly as possible, the designer needs to know what flexibility is available to them in implementing the application, while still meeting the functional requirements of the application. Here are some questions which may be of value to the designer:
1. To accommodate necessary maintenance activities, may the system operate for brief periods during which it would:
a. Perform inquiry but not update?
b. Accept update requests from the user, but not actually update the DB until after the maintenance activities have completed?
2. For an outage requiring recovery of data, is it more important to:
c. Restore service as quickly as possible, even if it means using data that is not completely up-to-date, or:
d. Recover all data to their current state before restoring service, even if this takes longer?
3. Should a user request be "in process" at the time of failure, can the user be relied on to re-enter the request following recovery of service?
4. Are there any non-technical considerations that might affect the availability of this system (such as a business policy which says that process A must not be made available to users unless process B is also available)?
Are any of the above design considerations expected to change over time?
For processes that are critical to the business, it is useful to identify alternatives which allow the most critical elements of those processes to appear functional even when portions of the system are temporarily unavailable. The ability to operate temporarily with reduced business function may be a way to help reduce the availability impact of interdependencies among critical processes and data.
1. Identify data to be protected
2. Identify the type of threats to which each type of data is exposed:
1. Identify threats to physical security:
- Theft of components
- Unauthorized physical access
- Physical safety of users
2. Identify the people who may be the sources of these threats:
- Data center staff
- Other IT staff (for example, development)
- Non-IT staff of the organization
- People outside the organization
3. Identify any special or unusual security requirements especially with respect to:
- Access to the system
- Encryption of data
- Auditability
4. Are there any general policies, such as Freedom of Information acts, that might influence the security design of this system?
5. Some packaged application solutions have their own security sub-systems. If you have a "given" package be aware of its security facilities.
In order to establish and classify the security requirements, you may want to use the following approach:
1. List the objects which require protection by logical or physical security.
2. Identify the exposure which is relevant to each object. Typical categories are:
- View access (breach of confidentiality), e.g. account information, client list, patents.
- Update access, i.e. modification of data for fraud, cover-up, diversion of funds.
- Loss of assets, i.e. somebody else gets a possession and it is no longer available to the owner (as distinguished from loss due to disaster). Examples are: client and prospect lists, contracts, etc.
Note that not all objects are sensitive to all of the above exposures.
3. Identify all the threats which are relevant to your environment. Examples are:
- Disgruntled employees
- Unauthorized employees
- Open terminal sessions in public place
- Hackers
- Line tapping
- Loss of equipment (e.g. portable PCs)
4. For each object establish which threat may apply and associate it with the particular exposure.
Note that you may have to review the security requirements for the object both in a static location (e.g. on a hard disk) as well as in transit (e.g. during transmission).
Since the design may extend the location of the object into unsecured areas, you may have to revisit this subject.
The security aspects of some system designs can be very demanding. They can dominate your design decisions. They could cause otherwise good options of structure and component selection to become unacceptable. So make a definite choice now as to whether the system that you are designing has particularly demanding security requirements. For example:
If you believe that you have special security demands then you should identify a Security Expert or Practitioner to assist you in the design aspects of your system.
|
Portions of the text herein are used under license from IBM Corporation |
|
|
Rational Unified
Process
|
