CHAPTER - 10
(Functional Requirements)
Created by:- Ramandeep Kaur
Functional Requirements
Functional requirements describe what the product has to do to support and enable the owner’s work. They should be, as far as possible, independent of the technology used by the eventual product. The Functional Requirements Specification is designed to be read by a general audience. Readers should understand the system, but no particular technical knowledge should be required to understand the document.
Uncovering the Functional Requirements
The scenario is a convenient way to work with stakeholders to determine the necessary functionality for a product use case. Each of the scenario’s steps is decomposed into its functional requirements. The collection of functional requirements reveals what the product has to do to fulfill the product use case.
This use case diagram shows the product generating the road de-icing schedule. This PUC is triggered by the Truck Depot Supervisor; the Thermal Mapping Database is a cooperative adjacent system providing information to the product use case upon request. The objective is to write enough functional requirements for your developers to build exactly the product your client is expecting and your actor needs to do the work.
Data, Your Secret Weapon
A class diagram showing the stored data that the business needs to predict the formation of ice on roads. A truck is dispatched to treat a road when the readings from the weather station and the forecast indicate the road section is about to freeze. There is a dependency between a product’s stored data and its functionality: You cannot have stored data unless there is some functionality to store and retrieve it, and functions can exist only if they process data.
Technological Requirements
Technological requirements arise purely because of the chosen technology. This need is a technological requirement; that is, it arises purely because of the chosen technology. If the designer had selected a different technology to handle this part of the work—say, a direct fiber-optic link—the result would be different technological requirements.
Grouping Requirements
A hierarchy of requirements. The work context is the highest-level statement of requirements; it is decomposed into the next level, the business events. The level below the business events comprises the product use cases, each of which is decomposed into a number of product use case steps. The lowest level includes the atomic requirements, each of which can be traced back to the hierarchy. Activity diagrams and user stories are also used to group atomic requirements. Features are a grouping often used by stakeholders from marketing or product version planning.
Feb 21, 2008 Microsoft Corp. announced a set of broad-reaching changes to its technology and business practices to increase the openness of its products and drive greater interoperability, opportunity and choice for developers, partners, customers and competitors. Microsoft is implementing four new interoperability principles and corresponding actions across its high-volume business products: (1) ensuring open connections; (2) promoting data portability; (3) enhancing support for industry standards; and (4) fostering more open engagement with customers and the industry, including open source communities.
ReplyDeleteWhen making a project, the requirements must be clear. In any case, communication is key. While it may be hard, the requirements must be set in a way that communicates exactly what to do and what the project must achieve, but at the same time, communicate to the stakeholders what is going to happen. A manager at Microsoft will be required to make these requirements and to clearly identify key points for stakeholders. At the end of the day, it is useless to work on a project when people do not have all the information.
ReplyDeleteYou can write requirements (for the moment) using two
ReplyDeletecomponents: a description and a rationale. The latter is the reason for the former’s existence. When you have sufficient functional requirements to achieve the outcome of a product use case, it is time to move on to the next one. As you progress through these PUCs, you may discover that a requirement you defined for one PUC also applies to other PUCs. Reuse the requirement you have already written by cross-referencing it to all relevant product use cases. When all of the product use cases have been treated this way, you will have defined the requirements that completely and unambiguously specify the functionality of the product.