Docstoc

SRS - Download as DOC

Document Sample
SRS - Download as DOC Powered By Docstoc
					                Software Requirements Specification
                                  Program X
                                        version 1.0




TUT            Software Systems Laboratory       00000 Course name
Author: <person in charge>                       Printed: 28.07.2000
Distribution: <who will get this document (and group members)>



State of document: draft                        Last modified: 04.08.2000
Program X                   Software Requirements Specification                       Version 1.0




VERSIOHISTORIA

Version     Date         Authors                     Description (changes, corrections...)
1.0         18.08.1998   Ikonen                      Original for HYTT
1.1         05.08.1998   Ikonen Jari                 Chapters 3. and 4. changed
1.2         19.08.1998   Peltonen                    Chapters 3. and 4. small changes
1.3         27.07.2000   Koivuniemi                  In English, small changes throughout
1.4         04.08.2000   Koivuniemi                  Corrections, more specifiacations added




01.03.11                                                                                       2/15
Program X                                        Software Requirements Specification                                                   Version 1.0




CONTENTS TABLE


1.     INTRODUCTION ....................................................................................................................... 5

     1.1       PURPOSE AND SCOPE ............................................................................................................ 5
     1.2       PRODUCT AND ENVIRONMENT .............................................................................................. 5
     1.3       DEFINITIONS, ACRONYMS AND ABBREVIATIONS ................................................................... 5
     1.4       REFERENCES ........................................................................................................................ 5
     1.5       OVERVIEW ........................................................................................................................... 5

2.     GENERAL DESCRIPTION ...................................................................................................... 7

     2.1       PRODUCT PERSPECTIVE ........................................................................................................ 7
     2.2       PRODUCT FUNCTIONS ........................................................................................................... 7
     2.3       USER CHARACTERISTICS ....................................................................................................... 7
     2.4       GENERAL CONTRAINS ........................................................................................................... 7
     2.5       ASSUMPTIONS AND DEPENDENCIES ...................................................................................... 7

3.     DATA AND DATABASE ........................................................................................................... 8

     3.1       CONTENTS OF INFORMATION ................................................................................................ 8
       3.1.1       Data element (entity) X ................................................................................................... 8
     3.2       INTENSITY OF USE................................................................................................................. 9
     3.3       CAPACITY ............................................................................................................................. 9

4.     FUNCTIONS ............................................................................................................................. 10

     4.1       GENERAL (OR SOME OTHER APPROPRIATE TOPIC) ............................................................... 10
     4.2       PROGRAM FUNCTIONS ........................................................................................................ 10
       4.2.1       Function X (each at its own subchapter) ...................................................................... 10

5.     INTERFACES ........................................................................................................................... 12

     5.1       HARDWARE INTERFACES .................................................................................................... 12
     5.2       SOFTWARE INTERFACES...................................................................................................... 12
     5.3       COMMUNICATIONS INTERFACES ......................................................................................... 12

6.     OTHER REQUIREMENTS..................................................................................................... 13

     6.1       PERFORMANCE AND RESPONSE TIMES ................................................................................ 13
     6.2       SECURITY, RECOVERY, USABILITY ...................................................................................... 13
     6.3       MAINTAINABILITY .............................................................................................................. 13
     6.4       TRANSFERABILITY/PORTABILITY ........................................................................................ 13
     6.5       OPERATOR’S TASK REQUIREMENTS .................................................................................... 13



01.03.11                                                                                                                                         3/15
Program X                                      Software Requirements Specification                                                 Version 1.0




7.     DESIGN CONSTRAINS .......................................................................................................... 14

     7.1      STANDARDS........................................................................................................................ 14
     7.2      HARDWARE CONSTRAINS ................................................................................................... 14
     7.3      SOFTWARE CONSTRAINS ..................................................................................................... 14
     7.4      OTHER CONSTRAINS ........................................................................................................... 14

8.     IDEAS FOR FURTHER DEVELOPMENT........................................................................... 15




01.03.11                                                                                                                                    4/15
Program X                         Software Requirements Specification                       Version 1.0




1.               INTRODUCTION


1.1              Purpose and scope
                 Why was this document made and to whom.

                 Does the SRS cover the all the functionalities of the product or just a part of it? Is
                 the user interface specified in this document or in the instruction manual [reference
                 to the manual].

1.2              Product and environment
                 Name of the product, purpose and benefits to the user.


1.3              Definitions, acronyms and abbreviations
                 Words and concepts that are not familiar to the reader (client/supplier) or might be
                 misunderstood. Thing that are not commonly in use or might be confusing. All
                 presented in alphabetical order.

                 Example: ASCII-table can be either 7-bits (ISO 10646) or 8-bits (ISO 8859-1).

                 Long and cryptic lettermonsters can be defused here.

                 Example: WEfI = Windowing Environment for Idiots, or if the working language is
                 not english then translated into proper language: WEfI = Windowing Environment
                 for Idiots, keskivertokäyttäjän käyttöliittymä). Procedures can vary betweed projects.

Table 1.3.1Notation used in this document.
                  Bold                                          function names, menu items, buttons
                  Italic                                        user inputs
                  CAPITAL LETTERS                               database names, filenames
                  [in square brackets]                          references


1.4              References
                 Special documents used in this document to build up the system if necessary (name,
                 version, date, and location). Possible documents can be Feasibility study, client
                 requirements, etc.

                 Example:

                  [StSh00]          Style Sheet for Documentation 27.06.2000, version 1.0,
                                    TUT             Software            Systems            Laboratory,
                                    http://www.acme.com/~batman... ... ...
                  [FeSt98]          Feasibility Study for project X, 01.01.1998, version 1.0.


1.5              Overview
                 Brief description of the structure of the document. Few words from every chapter.

                 Example:


01.03.11                                                                                           5/15
Program X                     Software Requirements Specification                          Version 1.0




            Chapter 1. contains the scope of the document, defines the product and terms used.

            Chapter 2. gives brief descriptions of all the fuction that the product has.

            Chapter 3. has the contents of information (database and dataflow).

            Chapter 4. defines the fuctions of the program. From each function there is
            description, inputs, outputs and possible actions.

            Chapter 5 specifies hardware, software and communications interfaces.

            Chapter 6 specifies all the non-functional features of the program. Like performance,
            response times, usability, etc.

            Chapter 7 contains restrictions applied to the design of the program. Standards,
            software and hardware constrains.

            Chapter 8 is reserved for ideas for the future development




01.03.11                                                                                         6/15
Program X                     Software Requirements Specification                         Version 1.0




2.          GENERAL DESCRIPTION

            Descriptions in this chapter should be in general level. All major aspects given in
            brief.

2.1         Product perspective
            Larger whole to what the program is connected/related to (software or hardware
            aspect). Is the product indepent or part of some bigger system.


2.2         Product functions
            Brief description of all the program characteristics (from chapter 4.). Inputs, outputs
            and functions in general level. There shouldn’t be anything here that is not explained
            in chapter 4.

            If data flow diagrams (or some other diagrams) are used in requirements
            specification the highest level diagram (context diagram) should be placed here.
            Functions and characteristics can then be easily explained with the diagram.

            If there are some special features in the program they should be mentioned here.
            Like if there is no printing options in the program, program can only be used with
            mouse or size of the screen in the product is very small, etc.

2.3         User characteristics
            User (maintenance personnel, sales personnel, CEO, etc.) and environment
            characteristics should be specified here. Does the program have an administrator?
            What kind of training program is needed for the users (what things are needed to
            know to use the program), what is the programs frequency of use (daily, hourly, once
            a week…), where do the the users fall in the company organization, etc.


2.4         General contrains
            General contrains concerning requirements specification and design processes
            (legistlation, protection, security, connections to other systems, etc.) from chapters 6.
            and 7.

2.5         Assumptions and dependencies
            Assumptions when the requirements specification is valid (certain operating system
            or hardware) from chapter 7.

            Readers in haste read only chapters 1. and 2. then they decide if the document is
            worth reading.




01.03.11                                                                                         7/15
Program X                     Software Requirements Specification                          Version 1.0




3.          DATA AND DATABASE


3.1         Contents of information
            Contents of information is one of the most important thing of the program. This is
            one reason why the relations of the data inside the program must be specified
            carefully (in logical level). Main purpose is to specify what information goes through
            the system and how it is manipulated. Precise structure of the database (physical
            level) is specified in the design phase so it is not included here. Exception to this rule
            is a very low level system or if the exact functions of the system is known.

            Contents of information in brief:
             contents of information in general level and relations of data inside the system
             other programs manipulating the contents of information (databases, other
               programs, other systems, etc.)
             support tools (recovery, backup, testing, etc.)
             administering, security and protection aspects

            Contents of information and relations of data can be illustrated here with class or use
            case diagram. Diagram illutrates the system in conceptual level, in other words it is
            not the implementation but a picture of how the program interacts with real world.
            Diagram is also explained here (merely the relations between data). Detail
            descriptions of the contents of information are presented in the subchapters.

            In the requirements specification document the information is presented in such
            detail level that in design phase the basic structure and relations between data is
            crystal. Goal is to come up with exact model that illustrates the real world in a
            ”readable” form.

            In this chapter there is a brief description from every data element (entity), the
            relations between data elements are carefully specified and attributes declared
            related to data element relations. Every data element (entity) and its functionalities
            are presented in their own subchapters like in 3.1.1.

            In this chapter it is worth mentioning if all the data is located in a hard drive or in
            main memory. Special notations used in contents of information should be specified
            here also for random reader.

3.1.1       Data element (entity) X
            Data elements are described by their functionalities. From every elelment there is...
             type (letter, text, decimal, etc.)
             size (lenght, space, etc.)
             description (what kind of information, not always necessary)

            If needed, the handling of data and rules of calculating the data should be specified
            here along with update criteria and rules. Like this:
             “Lenght of the project is calculated with form EndingDate - StartingDate”.
             “Login for the applicant is generated with this program and this is the only
                program allowed to change it”.




01.03.11                                                                                         8/15
Program X                    Software Requirements Specification                        Version 1.0




3.2         Intensity of use
            Intensity of use is approximated by the worst case.

            Examples:
             Program is only used daily from 0900 to 1600.
             Program is used in 10min intervals.
             Program is run every day at 2305.

            (response times can be found from 6.1.)


3.3         Capacity
            Capacity or data handling capability. What is the maximun load that the system can
            handle. Example: “There are maximun of 3000 cards in the system”.

            Special requirements that are needed to prevent the system from crashing.




01.03.11                                                                                      9/15
Program X                    Software Requirements Specification                         Version 1.0




4.          FUNCTIONS


4.1         General (or some other appropriate topic)
            In here it is possible to list all things similar to every function. Like some key
            combinations (Esc, Alt-F4, ^C (CTRL-C), !sh, ^Z, F1...) are those in use or not. Is
            there a support for special characters. Is there a difference between CAPITAL and
            small letters. Is the program designed to be used with mouse, keyboard or both. Is
            the length of file names specified.

            It is possible to specify here things like changing the window size, moving the
            window, default buttons, etc.. Language of the program should be specified here
            (documents, user interface, code comments, etc.)

4.2         Program functions
            It is possible to present program functions in hierarchical order with data flow
            diagrams. This is one way of dividing the problem into smaller parts and all the
            functions are specified. Idea is that reader has somekind of feeling what functions are
            there in the program and how can they be accessed by the user. Data flow diagrams,
            class diagrams, use case diagram, screen charts are especially usefull here. Only high
            level diagrams should be presented here.

            User interface is defined in some detail in the requirements specification phase so
            that the basic outline is clear when entering the design phase. Usually it is impossible
            or unnecessary to specify the user interface with high detail because some
            reguirements can still change along the process. The main principle in this document
            is defining the functions and only those parts necessary from user interface.

            If the user interface is specified here then the main focus should be in screens,
            windows, graphics, commands, keys, reports, etc.. How is scrolling controlled, help
            for the user, error messages and actions after them, printing to screen and to external
            device.

            User interface screens don’t need to be implemented with graphical tools they can be
            in plain text form.

            Program functions should be examined thorough and one by one so that each
            function is presented in its own subchapter. This keeps the document readable,
            makes references easier and gives the customer a change to check that all the
            fuctions are specified.
4.2.1       Function X (each at its own subchapter)
            Functions can be often presented in hierarchical order. In these subchapters each
            function is specified separately. For example, place for 2nd level data flow diagram
            is here. Functions can then be easily explained by referring to the diagram.

            When specifying the functions nothing is left out. Specification is complete and
            structurally written. Usage of examples is recommended. Functions can be specified
            like this:
             function description
             purpose
             inputs (what, from, how much, unit, values allowed, etc.)
             handling (parameters, rules of handling, etc.)


01.03.11                                                                                      10/15
Program X                    Software Requirements Specification                      Version 1.0




             outputs
             error handling (how is handled, how is user informed, what is done after error has
              occured)




01.03.11                                                                                   11/15
Program X                   Software Requirements Specification                      Version 1.0




5.          INTERFACES


5.1         Hardware interfaces
            Is the system using external devices like printer? If printing is not possible that
            should be mentioned here also.

5.2         Software interfaces
            Is the system using/connected to any outside software? External databases and such.
            Some information about the interface and a source where the exact specification can
            be found.

            If the system is connected directly to some program then the exact version of that
            program should be mentioned here.

5.3         Communications interfaces
            Is the system using communications interfaces like modem or LAN? Is the
            communication handled by your software or some other like the operating system?




01.03.11                                                                                  12/15
Program X                    Software Requirements Specification                      Version 1.0




6.          OTHER REQUIREMENTS


6.1         Performance and response times
            Static: how many terminals, how many files, etc.
            Dynamic: how many events per time unit.

            Response times can be specified like this: ”95% of the events go under 1 sec, max
            time is 5 secs”.

            In some realtime systems the response times can specified so that the time must not
            be under the minimum value given. Example: fastest response time must be 0.2 sec
            and the longest 20 secs.


6.2         Security, recovery, usability
            Usability in a mobile phone center can be like: Center can be out of order three (3)
            minutes per year or something like that.

            How is recovery handled in case of powerdown or harddisk failure?

            Is it possible for project personnel to accidently delete some files? How is security
            taken care of? Backups?


6.3         Maintainability
            Important chapter if there is no separate manual for maintaining the program. How
            easy is the program to maintain? Is it easy to change the user interface, database,
            communications protocol, etc.).

6.4         Transferability/portability
            Is this concidered in any way?.

            Are there any other systems that the program is compatible with (operating systems,
            windowing environments, etc.)?

6.5         Operator’s task requirements
            Are there any other tasks that the user needs to know/do before he/she can use the
            system? Like remove old log files, remove temporary files, set path or environment
            variables, etc.




01.03.11                                                                                    13/15
Program X                   Software Requirements Specification                       Version 1.0




7.          DESIGN CONSTRAINS


7.1         Standards
            Are there any standars, rules, recommendations, directives, instructions, etc. that
            apply to the program (documentation, coding, etc.).


7.2         Hardware constrains
            Hardware constrains are specified here. If the current system is the only one where
            the program works then it should defined here: CPU 80386DX, 4 Mb RAM, 330 Mb
            HD (X Mb reserved for the program, Y Mb free working space)

            Hardware requirements can be specified in some cases with the operating system:
            Program works in Windows 98 or Windows NT 5.0, then the harware constrains
            come from the OS.

            Hardware can be specified with minimum or recommended requirements.


7.3         Software constrains
            If the program only works in the current software environment then it should be
            defined here: database is Paradox 4.5 DOS or Ingres 6.2., operating system is OS/2 v
            2.0 or Linux 1.1.42.

            There is ”Windows” elsewhere in this documents but here it is specified in more
            detail like “Windows 95 OSR 2”


7.4         Other constrains
            Other possible constrains (usually coming from user)




01.03.11                                                                                   14/15
Program X                    Software Requirements Specification                      Version 1.0




8.          IDEAS FOR FURTHER DEVELOPMENT

            Ideas that have been under concideration during the project. Things that will not be
            implemented in this project because of lack of time, money, interest, resources, etc.




01.03.11                                                                                    15/15

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:84
posted:3/1/2011
language:Esperanto
pages:15