Business Requirement Gathering: Chapter 10 - Functional Requirements

1.     What is functional requirement:

·        Specify what the product must do to satisfy the work or business

·        Independent of any technology used by the product

·        Design a solution for the functional requirements

·        Add the technological requirements that are needed for the solution

·        Technological requirements are sometimes packaged together with the business requirements

·        Contract for building the product

·        Must have sufficient detail (describe how the product will perform, developer to construct or correct the product)

2.      Level of details:

·        Should be written as a single active sentence with one verb

·        If the use of “and” indicates more than one requirement, they should be separated

·        Written as a single sentence, the requirement is more easily tested

·        Always be measurable

·        The use of “must” is used for critical requirements and “should” for non-critical requirements

·        Critical requirement must be met for the project to be successful

3.      Description and Rationale:

·        Need a what, the description, and a why, the rationale

·        The description points to the solution

·        The rationale makes the need visible and indicates how much attention the requirement should get

·        Lead to a clearer requirement

4.      Data, Your Secret Weapon:

·        Data model: to show functionality of the product

·        Data dictionary: define what has been used in the data model and serves as part of the specification of the functional requirements

5.      Exceptions and Alternatives:

·        Exceptions: unwanted but inevitable deviations caused by errors in processing or incorrect action

·        Alternatives: if variations are allowed, requirements must include what to do

6.      Conditional requirements:

·        Must include what to do when certain processing requirements occur

7.      Avoiding Ambiguity:

·        Be aware of ambiguity and misunderstanding

·        Use simple language and terms that all stakeholders will understand

·        Use terms that relate to the client’s work area

·        Only use acronyms that are well-known to all stakeholders

·        Uniquely identify each requirement

·        Do not use slang, words that have more than one meaning, pronouns rather than subjects or object nouns

·        Be consistent with the data dictionary

·        Read written requirements aloud

·        Confirm understanding with the clients

8. Technological Requirements:

·        Functionality needed because of the chosen technology

·        Make the chosen implementation work

·        Secure connection to the internet

·        Introduced after the business requirements

·        Technological Requirements should be clearly identified

·        Should be separately documented when packaged with business requirements under Functional Requirements

9.  Grouping Requirements:

·        Grouped by use case or feature

·        Related groups of requirements become easier to discover

·        Test for completeness of the functionality

10.  Alternatives to Functional Requirements:

·        Scenarios: a series of stakeholder recognize steps for internal construction of products

·        User Story: An Agile tool to start the specification process

·        Business Process Model: activity models using tools with process descriptions

11.  Requirements for COTS:

·        Commercial off-the-shelf products

·        Installed software from vendors

·        Alternative to building the needed functionality

·        Interfaces for data inputs and outputs need review

·        Discovers and understands the functionality differences

·        May require configuration or modification

·        Changing the organization to match COTS