Software Requirements Specification

Student Information System (SIS) Software Design Document

Student Information System [responsibility name]Date-Month-YearVersion. 1.x

______________________________ ( ) [Project Lead]

______________________________( ) [Project Manager]

Group1ID 52441325 ID 52441328 ID 52441329 ID 52441337 ID 52441343

TABLE CONTENTS1Introduction11.1Purpose11.2Scope11.3Definitions, Acronyms, and Abbreviations31.4References32Design Overview32.1Background Information32.2Alternatives33User Characteristics34Requirements and Constraints34.1Performance Requirements34.2Security Requirements44.3Design Constraints45System Architecture46Detailed Design46.1Description for Component n46.1.1Processing for Component n46.1.2Component n Interface Description47Data Architecture57.1Data Analysis57.2Output Specifications57.3Logical Database Model57.4Data Conversion58Interface Requirements58.1Required Interfaces58.2External System Dependencies79User Interface79.1[Module X] Interface Design79.2Functionality710Non-Functional Requirements7

Student Information System (SIS) Software Design DocumentSoftware Engineering Semester 2/2009iv

Software Engineering Semester 2/2009Student Information System (SIS) Software Design Document

1King Mongkuts University of Technology Thonburi : Software Engineering [Group1]ivVersion 1.0ivKing Mongkuts University of Technology Thonburi : Software Engineering [Group1]

Revision Sheet

Revision NumberDateBrief summary of changes

01DateBaseline draft document

[Project Name] Software Requirements Management PlanDate

Software Engineering Semester 2/2009Student Information System (SIS) Software Design Document

ivRevision SheetVersion 1.0Version 1.0vIntroduction[This Software Design Document template is designed to facilitate the definition of processes and procedures relating to software design activities. This template was developed using IEEE Std 1016-1998, IEEE Recommended Practice for Software Design Descriptions which has been adapted to support CMMI requirements. As stated in IEEE 1016, The SDD shows how the software system will be structured to satisfy the requirements identified in the software requirements specification (IEEE Std 830-1998). It is a translation of requirements into a description of the software structure, software components, interfaces, and data necessary for implementation. In essence, the SDD becomes a detailed blueprint for the implementation activity.

Information displayed in blocked text under each section offer suggested items for inclusion in the Software Design Document.

Information displayed in brackets is explanatory. Delete the bracketed text items and add your project-specific input. These items are food for thought on the section they address. The document organization proposed here is offered as an example of one of the many ways that the design activities may be documented.

This section should explain the purpose and scope of project software design, as well as, provide clarification of definitions, acronyms, and references. This section should also provide an overview of the project.]Purpose[This subsection should explain the purpose for writing an SDD for this project and describe the intended audience for the SDD.]Scope[This subsection should:

Identify the software products to be produced, by name Explain what the software products will, and if necessary, will not do Describe the application of the software being specified including all relevant goals, objectives, and benefits from producing the software.

Provide a description of the dominant design methodology. Provide a brief overview of the product architecture. Briefly describe the external systems with which this system must interface. Also explain how this document might evolve throughout the project lifecycle.]

Definitions, Acronyms, and Abbreviations[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the SDD.]References[This subsection should list all references used within the SDD. All relationships to other plans and policies should be described as well as existing design standards.]Design OverviewBackground Information[This section should briefly present background information relevant to the development of the system design. All stakeholders should be identified and their contact information provided. A description of associated project risks and issues may also be presented along with assumptions and dependencies critical to project success. Describe the business processes that will be modeled by the system.]Alternatives[All design alternatives considered, and the rationale for non-acceptance, should be briefly addressed in this section.]User Characteristics[Identify the potential system users. Specify the levels of expertise needed by the various users and indicate how each user will interact with the system. Describe how the system design will meet specific user requirements.]Requirements and ConstraintsPerformance Requirements[This section should describe how the proposed design will ensure that all associated performance requirements will be met.]Security Requirements[This section should describe how the proposed design will ensure that all associated security requirements will be met. List any access restrictions for the various types of system users. Describe any access code systems used in the software. Identify any safeguards that protect the system and its data. Specify communications security requirements.]Design Constraints[This section should describe how requirements that place constraints on the system design will be addressed. List all dependencies and limitations that may affect the software. Examples include budget and schedule constraints, staffing issues, availability of components, etc.]System Architecture[This section should provide a description of the architectural design. All entities should be described as well as their interdependent relationships. A top-level diagram may be provided.]Detailed Design[Decompose the system into design components that will interact with and transform data to perform the system objectives. Assign a unique name to each component, and group these components by type, e.g., class, object, procedure. Describe how each component satisfies system requirements. In user terminology, specify the inputs, outputs, and transformation rules for each component. Depict how the components depend on one another. Each component should be described as shown by the headers listed in section 8.1.]Description for Component nProcessing for Component nComponent n Interface DescriptionData Architecture[This section should describe the data structures to be used in support of the implementation. If these include databases, define the table structure including full field descriptions, relationships, and critical database objects. Graphical languages are appropriate. If this information is often provided in a separate Database Design Document, if this is the case simply refer to this document and omit the remainder of section 6.]Data Analysis[A brief description of the procedures used in support of data analysis activities should be described in this section. Any analysis of the data that resulted in a change to the system design, or that impacted system design, should be noted.]Output Specifications[All designs supporting requirements for system outputs should be described in this section. These may include designs to support reporting, printing, email, etc.]Logical Database Model[Identify specific data elements and logical data groupings that are stored and processed by the design components in 6. Outline data dependencies, relationships, and integrity rules in a data dictionary. Specify the format and attributes of all data elements or data groupings. A logical model of data flow, depicting how design elements transform input data into outputs should be developed and presented here.]Data Conversion[This section should describe all design requirements in support of data conversion activities. This may be covered in a separate data migration plan, but if it is not, it should be documented in the design documentation. The migration and validation of any converted legacy data should be described.]Interface RequirementsRequired Interfaces[This section should describe all interfaces required in support of hardware and software communications. If an Interface Control Document was developed along with the Software Requirements Specification it should be referenced here. The effectiveness of how the system design addresses relevant interface issues should be discussed. Specify how the product will interface with other systems. For each interface, describe the inputs and outputs for the interacting systems. Explain how data is formatted for transmission and validated upon arrival. Note the frequency of data exchange.]

External System Dependencies[This section should provide a description of all external system dependencies. A diagram may be used to provide a description of the system with each processor and device indicated. ]User Interface[Describe the user interface and the operating environment, including the menu hierarchy, data entry screens, display screens, online help, and system messages. Specify where in this environment the necessary inputs are made, and list the methods of data outputs, e.g., printer, screen, file. ][Module X] Interface Design[This section should contain screen Images and a description of all associated design rules.]Functionality[All objects and actions should be described in this section. Any reuse of existing components should be identified.]Non-Functional Requirements[This section should address design items associated with non-functional requirements relating to system performance, security, licensing, language, or other related items. ]6Version 1.0 (Draft)2King Mongkuts University of Technology Thonburi : Software Engineering [Group1]Appendix A// Requirements Traceability Matrix

[This can be annotated on the Requirements Traceability Matrix, in the Design Review document, or in the Configuration Management System.][Organization/Project ]Requirements Traceability Matrix(RTM)

Requirement NamePriority

RiskSRS Ref.SDD Ref.Validation Method(s) *Formal Test Paragraph

Input Personnel DataHL3.1.16.2.3A6.3.14

Store Personnel DataMH3.1.26.2.2A,I6.3.17

* Validation Method(s)D-DemonstrationT-TestA-AnalysisI-Inspection

Field Descriptions

1.Requirement NameA short description of the requirement to be satisfied

2.PriorityHigh (H), Medium (M), Low (L); to be negotiated with customer and remains fixed throughout software development lifecycle

3.RiskHigh (H), Medium (M), Low (L); determined by technical staff and will change thoughout software development lifecycle

4.SRS Ref.Paragraph number from section 4 of the SRS.

5.SDD Ref.Paragraph number from section 6 of the SDD.

6.Validation Method(s)Method to be used to validate that the requirement has been satisfied.

7.Formal Test ParagraphThis column will provide a linkage between the SRS and the software Test Plan. This will indicate the test to be executed to satisfy the requirement. (This column will be further defined in later EPG plans.)

8Version 1.0

11King Mongkuts University of Technology Thonburi : Software Engineering [Group1]