Details of the responsible personnel, who will be handle the information, input the queries and details. ν H/M/L is the relative priority of that non-functional requirement. This has a specific engineering meaning. Does your team have to reach consensus? Stakeholders’ Requirements 3. Supporting Information GOTOBUTTON _Toc363403557 PAGEREF _Toc363403557 15
1. Formally in writing, email or phone call? Provide a cover page that includes the document name, product name, customer name, team name, team member names, and the current date. $
Ζ 4� a$ $
Ζ
€π4� a$
Ζ
€π4� 0 2 D E � ε ) � Ω η ! Drawings are good, but remember this is a description of what the system needs to do, not how you are going to build it. Top-Level System/Component Description 2. The chart below is optional (it can be confusing) and is for demonstrating tradeoff analysis between different non-functional requirements. They might include:
(1) Report format
(2) Data naming
(3) Accounting procedures
(4) Audit Tracing
For example, this could specify the requirement for software to trace processing activity. plant I&C system. μ The design of this document help to understand the system, technical & component needs to complete a project. Remember to check with the customer – they should prioritize the requirements and decide what does and does not get done. %PDF-1.5
2.4 Constraints
Provide a general description of any other items that will limit the developer's options. Tailor this to your needs, removing explanatory comments as you go along. Can the customer just call up and ask for something new? Instead, it provides a background for those requirements, which are defined in section 3, and makes them easier to understand. In such cases, organize the specific requirements for multiple hierarchies tailored to the specific needs of the system under specification. 3.2.2.m Process m
3.2.2.m.1 Input data entities
3.2.2.m.2 Algorithm or formula of process
3.2.2.m.3 Affected data entities
3.2.3 Data construct specifications
3.2.3.1 Construct 1
3.2.3.1.1 Record type
3.2.3.1.2 Constituent fields
3.2.3.2 Construct 2
3.2.3.2.1 Record type
3.2.3.2.2 Constituent fields
…..
3.2.3.p Construct p
3.2.3.p.1 Record type
3.2.3.p.2 Constituent fields
3.2.4 Data dictionary
3.2.4.1 Data element 1
3.2.4.1.1 Name
3.2.4.1.2 Representation
3.2.4.1.3 Units/Format
3.2.4.1.4 Precision/Accuracy
3.2.4.1.5 Range
3.2.4.2 Data element 2
3.2.4.2.1 Name
3.2.4.2.2 Representation
3.2.4.2.3 Units/Format
3.2.4.2.4 Precision/Accuracy
3.2.4.2.5 Range
…..
3.2.4.q Data element q
3.2.4.q.1 Name
3.2.4.q.2 Representation
3.2.4.q.3 Units/Format
3.2.4.q.4 Precision/Accuracy
3.2.4.q.5 Range
3.3 Performance Requirements
3.4 Design Constraints
3.5 Software system attributes
3.6 Other requirements
Outline for SRS Section 3
Showing multiple organizations (Can’t decide? Usually functional requirements contain specific information of inputs, outputs and general engineering requirements. Specific requirements in this area could include the need to:
Utilize certain cryptographic techniques
Keep specific log or history data sets
Assign certain functions to different modules
Restrict communications between some areas of the program
Check data integrity for critical variables
3.6.4 Maintainability
Specify attributes of software that relate to the ease of maintenance of the software itself. Then glob it all together)
3 Specific Requirements
3.1 External interface requirements
User interfaces
Hardware interfaces
Software interfaces
Communications interfaces
Functional requirements
3.2.1 User class 1
3.2.1.1 Feature 1.1
3.2.1.1.1 Introduction/Purpose of feature
3.2.1.1.2 Stimulus/Response sequence
3.2.1.1.3 Associated functional requirements
3.2.1.2 Feature 1.2
3.2.1.2.1 Introduction/Purpose of feature
3.2.1.2.2 Stimulus/Response sequence
3.2.1.2.3 Associated functional requirements
…..
3.2.1.m Feature 1.m
3.2.1.m.1 Introduction/Purpose of feature
3.2.1.m.2 Stimulus/Response sequence
3.2.1.m.3 Associated functional requirements
3.2.2 User class 2
.....
3.2.n User class n
.....
3.3 Performance Requirements
3.4 Design Constraints
3.5 Software system attributes
3.6 Other requirements
Outline for SRS Section 3
Organized by Use Case (Good when following UML development)
3. Remember this is not design. <>/ProcSet[/PDF/Text/ImageB/ImageC/ImageI] >>/MediaBox[ 0 0 612 792] /Contents 4 0 R/Group<>/Tabs/S/StructParents 0>>
3.6.3 Security
Specify the factors that would protect the software from accidental or malicious access, use, modification, destruction, or disclosure. 2.1.7 Operations
Specify the normal and special operations required by the user such as:
The various modes of operations in the user organization
Periods of interactive operations and periods of unattended operations
Data processing support functions
Backup and recovery operations
(Note: This is sometimes specified as part of the User Interfaces section.)