Templates for specifying business, functional and software requirements
Mục Lục
BUSINESS REQUIREMENTS DOCUMENT (BRD)
Business requirements, typically defined by business analysts in collaboration with other project stakeholders, describe what deliverables are needed, but not how to accomplish them. BRD is particularly useful for middle and upper management, and contains details such as:
1. Project overview
Project overview including executive summary, business context/ background, vision and mission/ mandate
2. Project objectives
Project objectives, problem statement and rationale (reason/ necessity for change/ as-is and to-be)
3. Stakeholders
Key business stakeholders (incl. list of UAs)
4. Success factors
Success factors & indication on cost versus benefit
5. Scope of work
High-level scope of work, as well as list of any out of scope items
6. Timelines
Timelines including deadlines and any key milestones
7. Assumptions & Dependencies
Assumptions and dependencies
8. Risks & challenges
Risks, known challenges and limitations/ constraints, and mitigation
9. Other considerations
Budgetary and other considerations (such as personnel requirements)
FUNCTIONAL REQUIREMENTS SPECIFICATION (FRS)
FRS, also referred to as Functional Requirements Document (FRD), Functional Specifications Document (FSD) or simply as functional specifications, is derived from the BRD, and defines how the software would meet the business requirements.
At a very high level, it should define input to the system, details of how the system should process the same and expected output. There neither seems to be a standardised format for writing functional specifications, nor there is guidance on the level of detail, but broadly speaking it should have enough detail for developers to know what to build, for testers to write test cases and test them and for the stakeholders to know (and see) exactly what it is that they would be getting.
Nothing should be left for interpretation; if not already brought out clearly, the same should be queried by developers and testers, and the document can be subsequently improved upon. Technical details, if, and to the extent, required may be provided. However, all non-functional requirements such as security, scalability, reliability etc. must be adhered to whilst designing the solution, and may not be repeated for each feature.
The following may be covered when writing functional specifications for every feature/ business requirement.
1. Feature overview
High-level description of feature/ functionality being specified along with context and its purpose
2. Accessing the feature
How to reach the screen offering a certain functionality
3. User interfaces
Screen/ GUI and its details: Detailed description of elements on a screen, their placement/ layout etc. explained with the help of wireframes/ mock-ups; to cite an example, for any form, the labels, placeholder text, field type, field widths, whether mandatory/ not, other custom validations and their messaging, help text/ tool-tip etc. should be defined.
4. User journey
Details of operations performed on each screen, i.e. workflows/ use cases/ activities permitted and user journey to complete each activity
5. Role-based access restrictions
Users allowed/ not allowed to see or use a feature or a screen/ field (role-based access)
6. Error handling
Approach for handling errors/ exceptions, including what message to display to user
7. Default configurations (if any)
Any applicable configurations, i.e. default settings for new record being created
8. Acceptance criteria
What acceptance criteria should be met for the feature implementation to be deemed as completed and signed off; Success factors should be clear and measurable.
Sample format: Given <situation> | When <input> | Then <output>
SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
SRS comprises user requirements for a system as well as detailed specifications of the system requirements. It is a description of the software system to be developed.
Key benefits of a well-written SRS are as follows.
- Establish the basis for agreement between the customers and the suppliers on what the software product is expected to do
- Reduce development effort by rigorously considering all requirements before design begins and therefore reduce later redesign, recoding and retesting
- Provide a basis for estimating costs and schedules
- Provide a baseline for validation and verification
- Facilitate easy transfer of the software product to new users or new machines
- Serve as a basis for later enhancement of the finished product
Following details should ideally not be included in the SRS as per IEEE guidance.
- SRS should not normally specify design items such as a) Partitioning the software into modules b) Allocating functions to the modules c) Describing the flow of information or control between modules d) Choosing data structures.
- The SRS should address the software product, not the process of producing the software product. Details such as cost, delivery schedules, reporting procedures, software development methods, acceptance criteria etc. should not be included in the SRS.
- Implementation details and detailed specifications.
Typically, SRS may include the following information:
1. Introduction
Project background, objectives and expected benefits, solution overview
2. External interfaces
Details of any external interfaces showing if and how the software interacts with people, other existing hardware/ software within the same environment/ system and external systems/ organisations. Block diagram showing the large components and inter-connections may be helpful.
3. Software and hardware requirements
Details of software and hardware environment. Requirement of software such as database, operating system, applications, platform/ development software etc., along with their details like version number etc. Hardware/ infrastructure details, configurations etc.
4. High-level functional requirements
Product functionalities at a high level, including list of functional requirements, and indicative use cases. Apportioning of requirements, i.e. if requirements may be delayed until a subsequent release
5. User types
Different types of users using the software (i.e. user roles and permissions), indicative use cases for each user role. Anticipated technical competency level of users may also be considered.
6. Architectural principles
Architectural principles such as reliability, portability, maintainability etc.
7. Design constraints
Constraints such as security considerations, development/ QA standards to be adopted, regulatory policies (i.e. privacy) etc. that may limit the developer’s options
8. Performance
Concurrent users, data volume to be handled (peak load and normal load), availability, response time, recovery time of various software functions and data etc.
9. Non-functional requirements
Non-functional requirements and considerations such as security, storage and backup, quality, version control, configurations management, audit logs etc.
10. Security requirements
Security requirements including application security, network and infrastructure and data, encryption guidelines etc.
11. Data/ information management requirements
Types of information saved in database, data governance model, frequency of use, access rights and mechanism, integrity constraints, data sources, list of data elements, data load, data transformation, data retention, Data Store/ Master Data Management, Data Flow Diagrams, Logical Data Model/ Data Dictionary etc.
12. Assumptions and dependencies
Assumptions and dependencies relevant to the project
GENERAL DOCUMENT GUIDELINES
Other elements that may be covered, irrespective of type of documents, i.e. BRD, FRS and SRS, are as follows:
- Title and published date
- Version control (version no., description, Author, Reviewed by, Approved by, Approved date)
- Table of contents
- List of figures
- List of tables
- Header, footer, page numbers
- Acronyms/ abbreviations
- Glossary of terms/ definitions
- Reference documents
REFERENCES
For BRD:
Business Requirements Document (BRD) – Understanding the basics
https://www.lucidchart.com/blog/tips-for-a-perfect-business-requirements-document
https://en.wikipedia.org/wiki/Business_requirements
https://www.indeed.com/career-advice/career-development/business-requirements-document-definition
http://www.requirementsnetwork.com/documents.htm
https://en.wikipedia.org/wiki/Software_requirements_specification
For FRS:
https://kisd.de/~tom/ia/downloads/andere_func_spec_tutorial.pdf
https://en.wikipedia.org/wiki/Functional_specification
https://www.guru99.com/functional-requirement-specification-example.html
Functional Requirements (Functional Requirement Specifications, Functional Specs, FRS, FS)
Functional Specification Document: What Is It and How To Create It?
https://medium.com/@darryl.snow/functional-specifications-6e1093102e76
For SRS:
https://medium.com/globalluxsoft/software-requirements-specification-what-do-you-need-to-know-22a6b8585945
IEEE (Institute of Electrical and Electronics Engineers) specification 830-1998 http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
https://searchsoftwarequality.techtarget.com/definition/software-requirements-specification
* * * *
![Toni Kroos là ai? [ sự thật về tiểu sử đầy đủ Toni Kroos ]](https://evbn.org/wp-content/uploads/New-Project-6635-1671934592.jpg)
