Chapter 10, Functional Requirements

FUNCTIONAL REQUIREMENTS


This chapter provides an information about the requirements that cause the product to do something i.e functional requirements. Functional requirements are the features of product that developer must implement so that users can accomplish their tasks. In functional requirements, product must do the actions. The Business Analysts understands the functional requirements for the product and then use that to describe about the product to developers.

PUC (Product Use Case) scenario enables the stakeholders, developers to have an overview of the functionality, to write  atomic requirements. 
Requirements are written as a single sentence with a single verb sch as in a form "The product shall....."
  • Example of functional requirements:
1. Engineer provides a scheduling date and district identifier: For this functional requirements are - 
The product shall accept a scheduling date.
The product shall accept a valid district identifier.

Description and Rationale:

Description of the requirement is defined as what the product does. For instance: The product shall record roads that have been treated.
Rationale is used to understand the requirement and indicates that the requirement is worthy of some attention. For instance: To be able to schedule untreated roads and highlight potential danger.

Data Models: Data models are also known class diagrams or entity relationship models. Data models are a rich indicator of the product's functionality. These shows the classes as rectangles. A class is a logical collection of data attributes that helps the product to carry out its functionality.

Data Dictionary: Data dictionary defines the meaning of the classes, attributes and associations of the data models.  It should also includes a definition of each attributes or association.


Exceptions and Alternatives: 

Exceptions: Exceptions are unwanted variations from the normal case that are caused by some incorrect actions. For example:What can go wrong.
Alternatives: Alternatives are acceptable variations from the normal case. For example: Choices you want.

Conditional Requirements:  Conditional requirements are used to add a condition to a requirement. If you write the requirement with a condition at the end, then it can be easy to find that requirement.
For example: The product shall play the music if requested.

Grouping Requirements: Grouping the functional requirements by use case make easy to discover related groups of requirements and to test the completeness of the functionality.

In summary, Functional requirements describes the processing of the product and this chapter suggests you to write requirements by using two components: a description and a rationale. If you have sufficient functional requirements to achieve the outcome of the product use case, then move on to the next one. 






 

Comments

  1. Karandeep singh23 April 2020 at 15:09

    DATA MODELS - The class model shows the classes (or entities) as rectangles. A class is a logical collection of data attributes that is needed by the product to carry out its functionality. The lines between the classes indicate an association between two classes, and the name on the line indicates the reason for the association. The asterisks and the 1s define the multiplicity of the association. The data model is not an indicator of the complete functionality. However, if you routinely build such a model, it will serve as part of the specification of your functional requirements.

    ReplyDelete
  2. Kerone Barnett23 April 2020 at 15:49

    Chapter 10 outlines a number of alternatives to writing functional requirements, namely using product use case scenarios to describe functionality, as well as using business use case scenarios. User stories can also be used to establish functional requirements and so too can Business Process Models where the BA uses an activity diagram to describe the functioning process for the product (establishing a visual step by step process). The other alternative described is using Commercial off the shelf products and tweaking upon acquisition to meet the company’s/ product’s needs.

    ReplyDelete
  3. Sukhpreet Singh23 April 2020 at 19:52

    Functional requirements – In this there is identification of requirements that are needed for the product so that to develop something.
    Formality guide – In this quick method is used for Rabbits project which is small and fast. This method produces heavy products. Requirements for horse project are written in communicable form. Complete and correct requirements as are needed for elephant project.
    Technological Requirements – The technology we choose for the development allows technological requirement to appear absolutely. Technological requirement needs to build a product with fixed or secured connection. Technological requirements are preferably for better performance but not for business reasons.

    ReplyDelete

Post a Comment

Popular posts from this blog

Chapter 7 – Business Requirements Gathering

Chapter 7 –  Understanding the Real Problem This chapter focuses on the Business Analyst “thinking above the line” and focusing on the true essence of the business. This requires reviewing the Brown Cow Model – that is looking at the area above the line – the “ What Now ”. This section examines the undiluted and core reason for the business’ existence. The next step would be to look at the future of the business, called the “Future What”. Examining these two areas helps the Business Analyst get to the heart of the business problem, rather than focus on possible solutions. With the right focus the Business Analyst is not distracted by what others may think the solution could be, but the BA delves and trawls through as much information as possible to accurately understand the business and how it functions, minus technology or automation. This determination to channel all efforts towards the core purpose of the business allows the BA to be more open to all possible solutions...
Read more

Chapter 3 - Business Requirements Gathering

Chapter 3 - Scoping the Business Problem This chapter focuses on Project Blastoff Deliverables such as Project Purpose, Scope of work, Stakeholders, Constraints, Names, Estimated Cost and Risks. The chapter refers to Scope, Stakeholders and Purpose as the Trinity confirming that these are core elements of any successful project blastoff. ·          For Project Scope, we must understand the extent of the work to be done and how this task (business improvement) will impact the current operational environment and its existing products and services. We must ensure that we accurately document the depth and breadth of the project. ·          For Project Purpose, we must accurately capture the quantifiable/ measurable business benefit to be gained from the completion of the project. ·          For Stakeholders, we must document all possible persons with a vest...
Read more

Chapter 4 - BUSINESS USE CASES

Business use cases  -Business events are useful to partition the work, but it is the work’s response to the  event that now captures the interest of the requirements analyst. For every business event, there is a preplanned response to it, known as a business use case (BUC). Rabbit Projects - it is important to have a rock-solid grasp of the business problem to be solved. Rabbits make use of business use cases to explore their problem domain before starting to formulate a solution. This approach does not add to the documentation load, and it lessens the time spent delivering inappropriate solutions. Horse Projects - Horse projects are more strategic than rabbits. they need more time to complete. There is also the possibility of using Business use case scenarios as the documentation to pass along to the developers. Elephant Projects - elephant projects have a large number of stakeholders, clear communication is both important and difficult. Business ...
Read more