Requirements Engineering Approach - Softed



[pic]

Requirements Methodology Pack

January 2008 Version 0.3

Section 6.3

Non-Functional and Supplementary Requirements - Template

Document Control

|Version |Date |Author |Reviewers |Reason |

|0.1 |7 Dec. 07 |A Wever | |Initial Draft |

|0.2 |? |Somebody?! | |Format, Style and Layout change |

|0.3 |18 Jan 08 |A Wever | |References and Hyperlinks updated. |

| | | | |Format, Style and Layout changed to remaining |

| | | | |Requirements Methodology Pack documents. |

|0.3 |8 Feb 2008 |Kate Wiltshire | |Updated Copyright/Headers & Footers/ Inserted SoftEd |

| | | | |Logo |

Copyright

Copyright © 2008 Software Education Group. All rights reserved.

Portions of this template have been adapted from the VOLERE Requirements Specification template and the Copyright © Atlantic Systems Guild.

Reference Documents

|Document ID |Version |Description |

| | | |

| | | |

Approver Sign-Off

|By providing my signature I acknowledge the accuracy of the content of this section/ document in the context of this project. |

|Name & Title |Date Signed |Area of Responsibility |

| | | |

| | | |

|-------------------- -------------- |-------------------------- | |

Table of Contents

Document Control 2

Reference Documents 2

Approver Sign-Off 2

Introduction 4

Purpose of the document 4

Scope 4

Acronyms and Abbreviations 4

References 4

Assumptions, dependencies and constraints 4

Assumptions and dependencies 4

Constraints 5

Non-functional requirements 6

Environmental requirements 6

Compliance requirements 6

Interface requirements 6

User Interfaces requirements 7

Hardware interfaces requirements 7

Software interfaces requirements 7

Communication interfaces requirements 7

Performance requirements 7

Security requirements 7

Quality requirements – Developers 8

Failure and disaster recovery requirements 8

Maintainability requirements 8

Quality requirements - Users 8

Accessibility requirements 8

Configurability requirements 9

Correctness requirements 9

Installability requirements 9

Usability requirements 9

Reliability requirements 10

Supplementary requirements 11

Open Issues 11

Appendix A: Analysis Models 12

Appendix B: To Be Determined List 13

Introduction

1 Purpose of the document

2 Scope

3 Acronyms and Abbreviations

|Term |Definition |

| | |

| | |

| | |

4 References

|Document name |Document title |Version |

| | | |

Assumptions, dependencies and constraints

1 Assumptions and dependencies

|Item |Assumptions / Dependencies |

| | |

| | |

| | |

2 Constraints

|Item |Constraint |

| | |

| | |

| | |

Non-functional requirements

Non-functional requirements are the properties or qualities the proposed systems functionality must have. The following section lists the most commonly used Non-functional requirements. NB Delete or add as required.

Each requirement should be uniquely identified with a sequence number or a meaningful tag of some kind. The Requirements shell defined below is an excellent way of capturing the necessary requirement attributes. For each requirement, attributes identified in the table must be captured.

|Requirements | |

|ID | |

|Background | |

|Requirements | |

|Statement | |

|Verification | |

|Business | |

|Priority | |

|Originator | |

|raised) | |

|Use Case/ Event |List of Use Cases/ Events that generated this requirement (Functional Requirements) or need this |

|Reference (s) |requirement (Non-Functional Requirements). |

1 Environmental requirements

Environmental requirements typically contain political, regulatory, market, standards, policies, physical constraints or globalisation requirements. An example is provided for a typical compliance requirement.

1 Compliance requirements

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download