jmi@devsim.mdcbbs.com (04/06/90)
In article <1990Apr5.144305.5483@quintro.uucp>, reb@quintro.uucp (Roger E. Benz) writes: > We are a small company seeking to improve our software engineering process. > One area that we are lacking in is documentation. After reading several > books and standards on how software requirement specs and design specs > should look I would realy like to see some examples. While I can't offer an example, this is sort of like a checklist that we use for determining what we want in a requirements document. Our customers use this to insure that the information we need is provided to build the products that they ask us for. ***THIS IS A "ROUGH DRAFT" COPY*** the final copy is considered proprietery and could never be released. This copy is not completed and is in some ways lacking, but it should provide an insite into the type and form of information that a requirements document for a software product requires. -------------------------------------------------------------------------------- Requirements Document Criteria Date: Authors: Revision: Acceptance: Introduction: Until this time, the development of requirements for systems that are to be implemented in software has been primarily an intuitive process without any formal method of determining the acceptability or applicability of these requirements. As a result, many key issues are often overlooked,requiring major changes and rework at later stages of the development process. While there amy appear to be redundancy in some of the items within this document, each is unique in viewpoint and should be addressed. Purpose: The objective of this document is to establish a minimal set of criteria for requirements of a software system. The issues addressed by this document are intended to define the acceptability of the requirements documents before the start of system design. It is recognized that not all of these issues will be applicable to all systems but it is necessary that each issue be considered. If an issue is not applicable to a given system, the reason must be stated in the requirements. CAVEAT: FOR ITEMS CONSIDERED "NOT APPLICABLE" BY THE REQUIREMENTS WRITER, THE ANSWERS WILL BE LEFT TO THE DISCRETION OF THE DESIGNER Use Of This Document: Both the software product designer and the author of the software product requirements shall use this document as a checklist against the software product requirements document. This will provide "one stop shopping" such that the designer does not have to go to the customer for additional information. Page 2 1. Problem statement 1.1 What problem is the product meant to solve? 1.2 Where does this product fit into the "big picture" ? 2. Environment 2.1 Cost 2.1.1 What is the limit of expenditures to be used to create the product? (i.e., dollars and/or engineering hours) 2.1.2 What is the limit of expenditures to be used to maintain the product? (i.e., dollars and/or engineering hours per unit time of use). 2.1.3 What other resources are available for the product development? (i.e., facilities/personnel and quantitative or qualitative limits) 2.1.4 What other resources are available for maintenance use during the product service life? (i.e., facilities/personnel and quantitative or qualitative limits) 2.1.5 What methods of progress measurement does the customer require to track the development task? (e.g., status reports, progress reports) 2.1.6 What are the milestones that shall be met? (e.g., schedules, deliveries) 2.2 Hardware/Software 2.2.1 What computers shall the product run on? (e.g., makes, models, particular installations) 2.2.2 What peripherals are required to interface with the product? (e.g., Page 3 terminals, hardcopy devices, tape drives, disk drives, displays, etc. Specify makes and models) 2.2.3 What unique interfaces does the product need to access? (e.g., cockpit hardware, microcomputer, test benches, etc. Specify makes and models) 2.2.4 On what operating system shall the product run? (i.e., operating system ID, revision level) 2.2.5 What database methods shall this product use? (e.g., ISAM, sequential, RDB, etc.) 2.2.6 With which specific database management products shall the product interface? (e.g., products protocol, etc.) 2.2.7 With what other external (foreign to this product) software products shall this product interface? (e.g., routines, libraries, product names, manufactures, suppliers, revision levels, etc.) 2.2.8 What are the size restrictions for the finished product? (e.g., bytes of code, text, embedded data, etc.) 2.2.9 How transportable shall the product be? (i.e., range of hardware/software enviroments under which the product will run) 2.3 Required Design Restrictions 2.3.1 What are the language restrictions for the product? (e.g., language names, versions; or maximum number of languages, etc.) 2.3.2 To what standards shall the product conform? (e.g., document titles, sources, revision levels, etc.) Page 4 2.4 Customers 2.4.1 Who is commissioning this product? (e.g, identify signatures of authority, etc.) 2.4.2 Who is to accept delivery? (e.g., identify signatures of authority, etc.) 2.4.3 What is the profile of the typical end user? (e.g., years of experience in some specified job, years of schooling, etc.) 2.4.4 What are the human factors criteria and how shall the success of the product in meeting the criteria be determined? (e.g., non-direct paths, non-standard user-interface, etc.) 2.5 Performance factors 2.5.1 What human support is required to operate the product? (e.g., Identify any runtime operations which the user or support personnel shall physically carry out in order to achieve any specified results, etc.) 2.5.2 What periods of time shall the product be available for operation? (e.g., hours per day, weekly schedule, etc.) 2.5.3 What criteria must the product meet regarding reliability of operation? 2.6 Operational Considerations 2.6.1 What methods shall be used to deliver the product? (e.g., data storage or transfer medium, etc.) 2.6.2 What are the restrictions on the installation of the product? How easily shall the product be to install? (e.g., classes of users, Page 5 numbers of users, access limitations, etc.) 2.6.3 To what degree shallthe operation of the product be successfully restricted to authorized users only? (e.g., classes of users, numbers of users, access limitations, etc.) 2.6.4 How shall product integrity be ensured? (e.g., data recovery source code recovery, etc.) 2.7 Maintainability 2.7.1 What support of the product after turnover to the customer is required? (e.g. training support, computer personel, etc) 2.7.2 Where might the requirements for the product expand in the future? (i.e. percentage chance of change) 3. Input 3.1 What are the input media ? (e.g., touch screen, keyboard, tape, etc.) 3.2 What is the format of the input ? (e.g., record layout) 3.3 What are the input items ? 3.4 What are the characteristics of each input item? (e.g., units, data type, sampling rate, etc. ) 3.5 For each item what is the acceptable level accuracy (tolerance)? 3.6 For each numeric item, how many significant digits are required ? 3.7 What are the descripitons and range for each data item? (e.g., month of the year, 0<x<100, file spec. etc.) Page 6 4. Process 4.1 Function 4.1.1 What processes is the product is to perform? 4.1.2 What are the algorithims? 4.1.3 What are the associations between algorithms and processes? 4.1.4 What are the modes of operation? (e.g., interactive, batch, etc.) 4.1.5 What options are available prior to startup? (e.g., switches, job parameters, etc.) 4.1.6 What options are available during runtime? (e.g., selection of I/O, job parameters, etc.) 4.1.7 How does the product use all the input data? 4.1.8 How does the product define all output data? 4.2 Timing 4.2.1 What are the constraints on response time? (e.g., acknowledge time, results time, etc.) 4.2.2 What are the constraints on iteration rate? (e.g., frames per second) 4.2.3 What is the latency required? (e.g., data transmission in multi- processing) 4.2.4 What are the CPU usage constraints for each process? 4.2.5 what are the CPU usage constraints for the product? Page 7 4.3 Error Handeling 4.3.1 What defines an error? (internal, user induced, system induced, disaster recovery, etc.) 4.3.2 How is each error communicated? (e.g., setting error flags sending message to user, etc.) 4.3.3 How does the product handle error condition? (e.g., program about, require new input, restore original enviroment, etc.) 5. Output 5.1 What are the output media ? (e.g., touch screen, keyboard, tape, etc) 5.2 What is the format of the output ? (e.g., record layout, etc.) 5.3 What are the output items? 5.4 What are the characteristics of each output item? (e.g., units, data type, sampling rate, etc.) 5.5 What is the acceptable level accuracy (e.g., tolerance)? 5.6 For each numeric item, how many significant digits are required ? 5.7 What are the descripitons and range for each data item? (e.g., month of the year, 0<x<100, file spec. etc.) 5.8 What are the expected values of output for a given set of inputs? 6. Documentation 6.1 Requirements 6.1.1 What documents have been referenced in the requirements document? Page 8 6.1.2 What additional documents are recommended for the development of the product? 6.1.3 What are the definitions of all the acronyms and technical terms? 6.1.4 What technical or legal authorizations are required to develope the product 6.1.5 Who has created and revised the requirements document and what are the dates of creation and revision? 6.2 Support 6.2.1 What type of support documentation shall the developer provide with the product? 6.2.2 To what standards shall the support documentation for the product conform? Page 9 -------------------------------------------------------------------------------- jmi jmi@dac.mdcbbs.com
hsrender@happy.colorado.edu (03/07/91)
Does anyone have any recommendations for software engineering texts? I'm currently teaching a course using Sommerville's latest, and although it's not bad, I've seen better. In particular, I'm considering a text by Shari Pfleeger and one called _Software Systems Engineering_ published by Wiley. If anyone has any other suggestions, please e-mail them to me. I'll post a summary if there's interest. Thanks. hal render render@zeppo.colorado.edu
ernest@pegasus.dsg.tandem.com (Ernest Hua) (03/21/91)
------------------------------------------------------------------------------- Who are the leading software testing researchers/institutes? Does IEEE have some testing standards? All comments and leads welcome! Please E-MAIL to ernest@tandem.com and I will post a summary. ------------------------------------------------------------------------------- Ernest Hua, Associate Design Engineer ernest@tandem.com Tandem Computers, 19333 Vallco Parkway, Cupertino, CA 95014 408-285-5580
kambic@iccgcc.decnet.ab.com (George X. Kambic, Allen-Bradley Inc.) (04/26/91)
In article <601@tivoli.UUCP>, alan@tivoli.UUCP (Alan R. Weiss) writes: > In article <36650004@hpopd.pwd.hp.com> daves@hpopd.pwd.hp.com (Dave Straker) writes: >>On measuring complexity... >> >>Before you measure anything, you should ask: Why am I doing this? >>What am I going to do with the information? What questions will >>it help answer? What decisions will it help me make? Note also that the answers you get may not be what you expect because the actual metrics may be answering other questions. Metrics aren't orthogonal. They are subject to improvement processes just like the software process itself. In other words, ask some questions, get some data, do some analysis, learn, and then repeat, repeat, repeat. Improve the process, and the metrics, and .......(wheels within wheels within wheels.....). GXKambic standard disclaimer.
kambic@iccgcc.decnet.ab.com (George X. Kambic, Allen-Bradley Inc.) (05/23/91)
In article <1991May15.223135.12381@m.cs.uiuc.edu>, marick@m.cs.uiuc.edu (Brian Marick) writes: > jls@netcom.COM (Jim Showalter) writes: [...] > The modern approach, following Taguchi, Deming, and company, has (in > principle) abandoned a measurement (cost of quality) and replaced it > with a system of faith that asserts that increased quality is *always* > cost-effective. In this case, the faith has worked better than the > metric. The system of faith is what software engineering has been operating on all along. Even Deming et. al. need some measurement. You cannot tell where you are going on faith alone. GXKambic standard disclaimer