- the Requirements List (RL) is produced by the customer to effectively describe the features and capabilities required by a proposed system.
- the Statement of User Requirements document is developed, based on the Requirements List.
- content is developed.
- how the Requirements List and Statement of User Requirements should be formatted.
- the Review/Approval process is performed.
- to achieve consistency across Requirements Lists which are derived from different sources. The resulting consistency allows for a more objective assessment of the requirements.
- a Statement of User Requirements (SUR) which can be effectively used as the basis for the development of a detailed user requirement specification.
- project staff have the means to identify and follow the processes involved with the Requirements Capture Process.
- to furnish a guide to the format and contents of the Requirements List.
Getting software requirements right can be difficult. Requirements collection is crucial to the development of successful information systems. To achieve a high level of software quality, it is essential that the Software Requirements Specification be developed in a systematic and comprehensive way. If this is done, the system will meet the user's needs, and will lead to user satisfaction. If it is not done, the software is likely to not meet the user's requirements, even if the software conforms with the specification and has few defects.
Developing Software Requirements Specifications: A Guide for Project Staff is an easy to use, step-by-step guide to developing high quality, effective Requirements Lists (RL), Statements of User Requirements (SUR) and Software Requirements Specifications (SRS). It prescribes both the format and content of these important documents.
Developing Software Requirements Specifications: A Guide for Project Staff is basically a 'plain English' version of IEEE Std 830 Guide to Software Requirements Specifications and IEEE Std P1233 - 1992 Guide for Developing System Requirements Specification, but with added features to enable project staff with average literacy skills to effectively develop a RL, SUR and SRS.
Documents prepared in compliance with this How To guide will therefore also comply with IEEE Std 830.
The SRS has business and technical considerations added which the customer may or may not be able to provide in the original Requirements List. The SRS provides all relevant detail about the proposed system to enable a development team to commence the design/development phases.
|
|
BENEFITS |
With this comprehensive guide to the preparation of the requirements capture and specification documents, you will learn how:
Feed back to the customer - the SRS allows the customer to verify that the analyst has understood the problem to be solved and the required behaviour of the software. As such the SRS must be presented in terms that can be understood by the customer. This most commonly means that it must be written in natural language. Should natural language prove inadequate to unambiguously describe complex requirements, modelling tools such as data flow diagrams, structured English, state transition diagrams and decision tables may be used providing they can be understood by the customer.
Problem decomposition - the physical act of writing the requirements down crystallises ideas, organises the information, surfaces and resolves conflicts and assists in the orderly decomposition of the larger problem into its component parts.
Input to design - the SRS is the primary reference for the development of the design. As such, it must contain an accurate and detailed description of system behaviour from which a system architect can devise a design solution.
A basis for product validation - the SRS is the primary source from which the developer produces a strategy for testing the end product. All requirements must therefore be verifiable. That is, the user must be able to devise a test to verify that the end product satisfies the requirement.
|
AVOIDING |
Why do projects fail? Much work has been done over the past 30 years on why and how a large proportion of systems are fail to achieve their purpose. They may be abandoned before the project is finished, or the system is developed, but the customer does not use it because it does not meet their requirements. The system may conform to its original SRS, and still be a failure if it does not do what the customer needs it to do.
User-Developer gap. The most common cause of not getting the requirements right is the existence of a cultural gap between supplier and customer. These differences result in poor or inhibited communication between the stakeholders in the requirements gathering process, leading to an incomplete or poorly defined statement of user requirements. Systems subsequently developed using such an SRS is unlikely to meet the user's needs and will in all likelihood be abandoned or need to be substantially reworked.
Closing the gap. The need for IS developers and users to collaborate has long been recognised by both the practitioner and academic worlds. A wide range of what might be called integrative processes have been developed to promote a collaborative approach to requirements analysis. These integrative processes include the ETHICS model for participative systems development, Joint Application Development and the use of particular people as integrators, such as the 'hybrid manager'. Where used, inte-grative processes are successful in improving the level of collaboration and effective communication between suppliers and customers.
Too hard? No! But despite their effectiveness in solving a widely recognised, highly expensive problem, in reality integrative processes are not generally used. In practice, they are seen as expensive, time-consuming and a threat to established ways of developing software. Tight project budgets and schedules put most integrative processes into the 'nice to have in an ideal world' category.
Technical writer as facilitator. The author has developed a proven integrative process that can substantially improve the chances of achieving successful project outcomes. A technical writer, who is already a member of the supplier development team, should take responsibility for the writing of the SRS. This is likely to be welcomed by the software engineers who would otherwise have to do it themselves. Technical writer's are usually able to understand both the technical point of view of the supplier, and the non-technical view of the customer/user, and as such can bridge the cultural divide. This suits them to act as a facilitator of communication between supplier and customer. If an appropriate template is used to develop the SRS, such as this one, it will be possible for a complete, correct, verifiable etc SRS to be developed, and this most dangerous of pitfalls for any development project to be avoided.
|
CONTENTS |
Click on the links below to view the complete Table of Contents and sample chapter. This gives you an indication of the scope and level of detail of this document, plus representative content of the actual document.
Download Table of Contents (pdf) | Download a sample of the book (pdf)
|
INCLUDED IN PACKAGE |
The book is supported by MS Word SRS template that you can use immediately by saving the template as your working document, then use the established structure of the template and the explanatory text in each section to fill in the required information. The explanatory text can then be deleted leaving you with a document that should impress your manager for its professional appearance and comprehensive content.
|
WHO SHOULD BUY IT |
Developing Software Requirements Specifications: A Guide for Project Staff is aimed at project staff from any industry sector; project managers, team leaders, any professional seeking to give themselves the means to develop a comprehensive and well-organised and presented Statement of User Requirements and/or Software Requirements Specification.
|
|
Ordering your PDF copy of Developing Software Requirements Specifications: A Guide for Project Staff for only US$19.95 direct from the author is easy. The printed book would sell for two or three times this price on the big online bookstores. It represents good value for money and a sound investment for any project manager, team leader or person wanting to develop their requirements gathering, analysis and management capabilities.
Transaction Record. Your credit card transaction will be processed using the latest secure processes by CCNow (One of the WWW oldest and most respected Credit Card processors). Your credit card transaction statement will show CCNow.
Delivery Information. You will receive a download link by email soon after you place the order. The download contains the book in PDF.
Money back guarantee. Your purchase comes with a money back guarantee if you are not completely satisfied.
|
|
ABOUT THE AUTHOR |
David Tuffley is a Senior Consultant with the Software Quality Institute and a Lecturer in the School of ICT at Griffith University in Australia. He has published extensively in the academic literature on the topic of this book, and also extensively in the commercial world of practical how-to guides for project managers and staff.
Long-established on-line bookseller. David has a proven track record in the production of practical, user-friendly guides for project managers since the early 1990's. He has been selling these guides to satisfied customers via the internet since the mid-1990's, making him one of the longest established on-line book-sellers on the WWW.
|
