To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
A software requirements specification (SRS) describes the requirements of a software product -- what it must do in order to function as expected. Realize that despite using the term "requirements," an SRS really is high-level design how of a product whose expected functioning is a presumed way to satisfy the REAL business requirements deliverable whats that provide value when satisfied. The software can work as expected but won't provide value unless it actually satisfies the REAL business requirements.
While a number of authors and organizations suggest SRS formats, many of which can be found through search engines, the most widely known version is described in IEEE Std. 830-1998. Standards can be purchased for what seems to have become much, much higher prices than I recall paying a few years ago. I'm appalled that it now costs $102 at http://webstore.ansi.org and at www.ieee.org, where IEEE members can buy it for $81. IEEE used to publish a very reasonably priced collection of several standards related to information systems, including 830; but the most recent used edition that I found listed on Amazon.com was from 1985. A number of books which Amazon also lists when you search for "IEEE 830" can be purchased for much less and describe the standard, and I suspect some may even reproduce the standard in its entirety.
The standard prescribes a format with a large number of separate sections, each addressing a different aspect of the software requirements. The prescribed SRS format is identical regardless of the software's use. That is, one prepares an SRS for a business portal essentially the same way one prepares an SRS for any other application.
The strength of the SRS is that the various sections are like a checklist to help assure you've addressed relevant topics, such as:
- Purpose, Scope, Definitions, References, Overview
- Product Perspective, Product Functions, User Characteristics, General Constraints, Assumptions and Dependencies
- Each Functional Requirement -- Introduction, Inputs, Processing, Outputs
- External Interface Requirements -- User, Hardware, Software, Communications
- Performance Requirements
- Design Constraints, Standards Compliance, Hardware Limitations
- Attributes (often called "nonfunctional requirements," "quality factors" or "ilities") such as Usability, Reliability, Maintainability and Security
- Other relevant requirements, such as for Database, Operations and Site Adaptation
Those who use SRSs frequently complain that the many sections lead to excessively lengthy documents which take too much time to prepare. Also, the SRS's multi-sectional format, which I liken to pigeon holes, can interfere with understandability because it can be easy to lose track of items in separate sections which need to be dealt with together.
The bigger issue is that SRSs not only don't assure that REAL business requirements are identified, but the common perception that an SRS is the requirements essentially assures that REAL business requirements won't be identified. An SRS's Purpose section is typically a few sentences describing desired value to be obtained, but it doesn't describe the business deliverable whats that will provide that value when delivered by the software product how. Creep mainly occurs when the product described in the SRS turns out not to be what's really needed -- that is, it fails to meet the REAL business requirements because they weren't defined adequately.
So, the way to prepare an SRS for a business portal is first to identify the REAL business requirements that the portal needs to accomplish. Many of the SRS topics do need to be addressed, but from a business and value standpoint. Then determine how best to address them, which may or may not turn out to be a business portal. Describe how the solution you want to implement should function in an SRS. You may also then want to write some use cases to describe the usage of it.
|
