Chapter 10 - Functional Requirements

A functional requirement document defines the functionality of a system or one of its subsystems. It also depends upon the type of software, expected users and the type of system where the software is used.
Functional requirements are the product features or its functions that must be designed directly for the users and there convenience. They define the functionality of the software.
Functional user requirements may be high-level statements of what the system should do but functional system requirements should also describe clearly about the system services in detail.
Here are some points to consider when doing the functional requirements:
  • Purpose of the Document
  • Scope
  • Business Processes
  • Functional Requirements
  • Data and Integration
  • Security Requirements

Level of details for functional requirements: 

  • Should be a single active sentence
  • Should use “and” wisely
  • Must be measurable
  • Use of “must” is used to critical requirements and “should” for non critical requirements
  • Too many similar words can result in confusion

Comments

  1. Harleen Virk2 December 2019 at 21:34

    Technological Requirements
    Technological Requirements are usefulness that is required absolutely on account of the picked innovation. In the case of the utilization case that creates the de-icing plan, the item connects with the warm mapping database. Assume the architect chooses that taking care of this communication by means of an Internet association is the best choice. In light of this innovative decision, the item has a need to build up a protected association. This need is a mechanical necessity; that is, it emerges absolutely in light of the picked innovation. In the event that the creator had chosen an alternate innovation to deal with this piece of the work—say, an immediate fiber-optic connection—the outcome would be distinctive mechanical prerequisites. The innovative necessities are not there for business reasons, but instead to make the picked usage work. We propose that these necessities either be recorded in a different determination or be distinguished obviously as mechanical prerequisites and recorded alongside the business prerequisites. Partners must see obviously why a prerequisite shows up in the particular, so it is significant that the mechanical necessities are not presented before the business necessities are completely comprehended

    ReplyDelete
  2. Parminder Singh3 December 2019 at 18:19


    LEVEL OF DETAIL OR GRANULARITY

    “The product shall . . .”; it makes the sentence active and focuses on communicating what the product is intended to do. It also provides a consistent form for the developers and other stakeholders who need to have a clear understanding of what the product is intended to do. You can of
    course substitute “will” for “shall” (some people claim is it grammatically better), but be consistent with whichever you choose.
    Incidentally, the word “shall” does not mean that you will definitely be able to find a solution to satisfy the requirement; it simply means that the requirement is a statement of the business intention. The developers are charged with deriving a technological solution to the requirement, and naturally there will be times when they cannot find a cost-effective solution. In the meantime, the requirement clarifies what the business needs the product to do.
    One last word on the form employed to write the requirements description: Sometimes people use a mixture of “shall,” “must,” “will,” “might,” “could” and so on, to indicate the priority of a requirement. This practice results in semantic confusion, and we advise against it. Instead, use one consistent form for writing your requirements’ descriptions (“The product

    shall . . .” is the most common) and use a separate attribute of the requirement to identify its priority.

    ReplyDelete
  3. Mariane3 December 2019 at 22:30

    Functional requirements should be composed of description and rational. The description is what Kent explained in his comment, when they're written as a single sentence with a single verb "the product shall...".
    As for the rationale, it shows why the requirement exists. Sometimes it's obvious, but in other circumstances it's a crucial component.
    Source: Mastering Business Requirements, pg 229
    Accessed on: Dec 04, 2019

    ReplyDelete

Post a Comment

Popular posts from this blog

Chapter 1 - What is Business Analysis?

Hello! Welcome to our Business Analysis blog.  We are Mariane, Harleen, Kent and Parminder, and we are Business Technology Management students at Red River College.  Throughout our Fall term we will be using this blog to share some important concepts regarding Business Analysis.  For our first post, we will start with the basics, and define exactly what is Business Analysis, and other important concepts related to it. According to BABOK, " Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value. "  Business analysis cannot work without having a representative to intermediate these practices within an enterprise. This professional is called a Business Analyst who is responsible for putting in practice the tasks desc...
Read more

Chapter-12 Fit Criteria and Rationale

Image
FORMALITY GUIDE Horse ventures need to have an exact and effectively shareable comprehension of the significance of necessities. It has been our experience that when the task has numerous partners—which is the standard for horse ventures—various partners relegate various implications to prerequisites. Including a reason and a fit basis to every necessity implies it is for all intents and purposes inconceivable for errors to happen. We prescribe that pony ventures incorporate both of these in their necessities. Elephant ventures must utilize methods of reasoning and fit criteria. These tasks are compelled to deliver a composed determination to be given on to some other gathering, either another piece of the association or an outsourcer. Having a detail containing just unambiguous, testable necessities is pivotal to elephant ventures on the off chance that the other party is to comprehend and, at that point convey the right item Scale of Measurement Any prerequisite can be ...
Read more

Chapter 5 - Investigating the Work

The starting point for any product that will be built is the owner's work.  The book mentions that business analysts go "trawling" after business requirements.  The first task in the business requirements gathering process is to understand and investigate the work that is being done. Once that's understood, then the "essence needs to be understood, that is the clean picture of the business, without technology.  In this chapter the "Brown Cow Model" is also introduced. Which is divided into 4 parts:  How-Now: shows the implementation of the work as it currently exists, including physical artifacts, people and processors to do the work.   What-Now: shows the real business policy (essence). No machines, people, or organizational departments. Future-What: shows the business as your owner wants to have it, but still with no technology applies to it. Future-How: shows the idealized future business policy, augmented with the technology and people ...
Read more