IEEE Recommended Practice for Software Requirements SpeciÞcations

@inproceedings{Tripp1993IEEERP,
  title={IEEE Recommended Practice for Software Requirements SpeciÞcations},
  author={Leonard L. Tripp and Edward R. Byrne and Paul R. Croll and Perry R Deweese and Robin Fralick and Marilyn Ginsberg-Finner and John Harauz and Mark Henley and Dennis Lawrence and David S. Maibor and Ray Milovanovic and James W. Moore and Tim Niesen and Dennis Rilling and Terence P. Rout and Richard F. Schmidt and Norman F. Schneidewind and David J. Schultz and B. Sherlund and Peter Voldner and Ron Wade and Syed Ali and Theodore K Atchinson and Mikhail Auguston and Robert E. Barry and Leo Beltracchi and H. Ronald Berlack and Richard E. Biehl and Michael Blackledge and Sandro Bologna and Juris Borzovs and Kathleen L Briggs and Maria Scott and Buck Michael Caldwell and James E. Cardow and Enrico A. Carrara and Lawrence Catchpole and Keith Chan and A. Cicu and Theo Clarke and S. Clermont and Rosemary Coleman and Virgil Lee and Cooper W W Geoff Cozens and Gregory T. Daich and Geoffrey Darnton and Taz Daughtrey and Bostjan K Derganc and Perry R Deweese and James Do and Evelyn S Dow and Carl Einar Dragstedt and Sherman Eagles and Christof Ebert and Leo Egan and Richard E. Fairley and John Fendrich and Jay Forster and Kirby Fortenberry and Eva Katharina Freund and Richard C. Fries and R. Fujii and Adel Ghannam and Garth John and Julio Glynn and L M Gonzalez-Sanz and David A Gunther and Jon Gustafson and Jon D. Hagar and Robert T Harauz and Herbert Harley and William A Hecht and Manfred He{\ss}ey and Mark William Hein and Mark Heinrich and Debra Henley and J W Herrmann and Jerry Horch and Peter L Huller and George K Hung and Frank V Jackelen and William S Jorgensen and George X Junk and Richard Kambic and Ron S Karcich and Judith S Kenett and Robert Joseph Kerner and Dwayne L Kierzyk and Shaye Knirk and Thomas M. Koenig and J. Kurihara and John B Lane and Lawrence Edward Dennis and Ching Fang and William M Lim and James J Lively and Dieter Longbucco and J J Look and Stan Lord and David J Magee and Harold Maibor and Robert A Mains and T. Martin and M. Matsubara and Patrick McAndrew and Christopher Mccray and Jerome W Mcmacken and Bret Mersky and Alan H. Michael and Celia Miller and James W Modell and Pavol Moore and Myrna L Navrat and Indradeb P Olson and A Pal and Peter T Polack and Lawrence Poon and Kenneth R Przybylski and Annette D Ptack and Dennis Reilly and Andrew P Rilling and Helmut Sage and Stephen R Sandmayr and H Schach and Norman P. Schaefer and David J Schneidewind and Lisa A. Schultz and Robert W Selmon and David M Shillato and Carl A Siefert and J. M. Singer and Richard S Sivak and Nancy M Sky and Melford E Smith and Harry M Smyre and Alfred R Sneed and Donald W Sorkowitz and Luca Sova and Julia Spotorno and Fred J Stesney and Christine Strauss and S Brown and Takeshita Toru and H Richard and Booker Thayer and Patricia Thomas and Theodore J Trellue and Glenn D Urbanowicz and Udo Venables and David D Voges and D. D. Walden and William McGregor Wallace and J. W. Walsh and C. Walz and Scott A Swhite-Partain and Phyllis Whitmire and Paul R Wolfgang and Natalie C Work and Janusz Yopconka and Geraldine Zalewski and P F Zimmerman and Zoll and Richard J Holleman and Don Heirman and Vice Chair and Judith Gorman and Member Emeritus and Valerie E Zelenty and S. Aggarwal and Clyde R Camp and James T. Carlo and Gary R Engmann and Harold E Epstein and Thomas F. Garrity and Ruben D Garzon and James Gurney and James D. Isaak and Lowell Johnson and Robert Kennelly and E G {\`O}al{\'o} Kiener and Joseph L Koepþnger and S. R. Lambert and Jim Logothetis and Donald C. Loughry and L Bruce Mcclung and Ronald C. Petersen and Gerald H. Peterson and J. B. Posey and Gary S. Robinson and Hans E Weinrich and Donald W. Zipse},
  year={1993}
}
The content and qualities of a good software requirements specification (SRS) are described and several sample SRS outlines are presented. This recommended practice is aimed at specifying requirements of software to be developed but also can be applied to assist in the selection of in-house and commercial software products. Guidelines for compliance with IEEE/EIA 12207.1-1997 are also provided. 
The proposal of functional user requirements generation
  • P. Tanuška, T. Skripcak
  • Computer Science
    2011 3rd International Conference on Computer Research and Development
  • 2011
TLDR
Basic method is proposed for the purpose of reusing Domain Model as basis of requirement generation in order to save initial time for defining user requirements in software engineering industry.
Quality Properties Evaluation for Software Requirements Specifications: An Exploratory Analysis
TLDR
This work is intended to be a compendium of the most important tendencies and strategies in the field that serves as a starting point for developing comprehensive models and tools for quality attributes evaluation in a SRS.
Verifying software requirements with XSLT
TLDR
This approach is based on the representation of software requirements in XML and the usage of the XSLT language not only to automatically generate requirements documents, but also to verify some desired quality properties and to compute some metrics.
User’s manual as a requirements specification: case studies
TLDR
It is argued that a user’s manual makes an excellent software requirements specification and several lessons learned from the experiences are discussed.
ser requirements modeling and analysis of software-intensive systems ichel
The increasing complexity of software systems makes Requirements Engineering activities both more important and more difficult. This article is about user requirements development, mainly the
Evaluating software specifications by comparison
TLDR
This paper proposes through a case study, an approach to evaluate and compare two Object-Z specifications of the same set of requirements and hence, provides a means to select the most appropriate one.
Eliciting required characteristics for usable requirements engineering approaches
TLDR
A market study intended to elicit a set of characteristics that could improve the usability of requirements engineering approaches, aimed toward software stakeholders such as developers, designers, customers, and managers at various software companies.
An XMLBased Approach for the Automatic Verification of Software Requirements Specifications
TLDR
This approach is based on the representation of software requirements in XML and the usage of the XSLT language not only to automatically generate requirements documents, but also to verify some desired quality properties and to automatically compute some metrics.
An Automated Approach for Verification of Software Requirements
TLDR
This approach is based on the representation of software requirements in XML and the usage of the XSLT language to automatically verify some desired quality properties and has been implemented in REM, an experimental requirements management tool.
Applying XML technologies in Requirements Verification
TLDR
This approach is based on the representation of software requirements in XML and the usage of the XSLT language not only to automatically generate requirements documents, but also to verify some desired quality properties and to automatically compute some defect–predictive metrics.
...
1
2
3
4
5
...

References

SHOWING 1-6 OF 6 REFERENCES
1 Compliance with information requirements of IEEE/EIA 12207
  • 1 Compliance with information requirements of IEEE/EIA 12207
2 discusses compliance with the generic content guideline (the ÒkindÓ of document) noted in column 3 of Table B.1 as a ÒdescriptionÓ. The generic content guidelines for a ÒdescriptionÓ appear in 5
  • 2 discusses compliance with the generic content guideline (the ÒkindÓ of document) noted in column 3 of Table B.1 as a ÒdescriptionÓ. The generic content guidelines for a ÒdescriptionÓ appear in 5
3 discusses compliance with the speciÞc requirements for a Software Requirements Description noted in column 4 of Table B.1 as prescribed by 6
  • 3 discusses compliance with the speciÞc requirements for a Software Requirements Description noted in column 4 of Table B.1 as prescribed by 6
4 discusses compliance with the life cycle data objectives of Annex H of IEEE/EIA 12207.0- 1996 as described in 4.2 of IEEE/EIA 12207
  • 4 discusses compliance with the life cycle data objectives of Annex H of IEEE/EIA 12207.0- 1996 as described in 4.2 of IEEE/EIA 12207
B.3.2 Compliance with generic content guidelines of IEEE/EIA 12207
  • B.3.2 Compliance with generic content guidelines of IEEE/EIA 12207
Copyright © 1998 IEEE. All rights reserved
  • Copyright © 1998 IEEE. All rights reserved