Chapter 10 Fundamental Requirements posted by Chelsia Palta


Introduction

 It is necessary to understand the difference between requirements. A need for your product to do something to support the owner’s business and a solution, the technological implementation of that requirement. It is also necessary to understand that while we are describing how to write requirements, the most important thing is to understand what the real business need is, and to communicate it in a way that ensures you get the right product built.


Formality Guide

 Rabbit projects- the small, fast projects are probably using some form of agile method. These methods emphasize iteration and not producing heavy documentation. Horse projects usually have a need to write their requirements in some communicable form. Compared to rabbits, horse projects have longer release cycles and geographically scattered stakeholders. Elephant projects must have a complete and correct requirements specification.


Functional Requirements

 Functional requirements are the things that your product does to support the work. They should be expressed independently from any technology that will be used to implement them. This separation might seem strange, as these requirements apply to an automated product. Keep in mind, however that you, as the business analyst, are not attempting to craft a technological solution, but rather to specify what that technological solution must do. How it achieves that outcome is a important for the designer.


Data Models and Technological Requirements

 Data models are also called class diagrams or entity relationship models. Data models are a rich indicator of the product’s functionality.
Technological requirements are functionality that is needed purely because of the chosen technology. 
Avoiding Ambiguity

 Whether the sources of your requirements consist of written documents or verbal statements from interviews, you should be aware of the enormous potential for ambiguity and the misunderstanding that ambiguity can cause. There are several sources which can arise ambiguity.

Comments

  1. Paramjeet Kaur Toor20 April 2020 at 18:35

    Good information about functional requirements as these represents what product must do so in Scotia Pay app we can say that NFC readers must connect when we are going to make payment as nobody will able to do payment without connecting phone to terminal so it is functional requirement for our project. These requirements allow us to focus on key or major requirements of a project which are necessary to develop a project.

    ReplyDelete
  2. Liliane Marino21 April 2020 at 16:00

    Thanks for sharing this information with us. It is very important to mention that you must not forget to document the exceptions and alternatives when you are working on the functional requirements. The exceptions are the unwanted but inevitable deviations from the normal case while alternatives are allowable variations from it.

    ReplyDelete
  3. Hassan Kamara23 April 2020 at 20:48

    The section on functional requirements was well thought out and written well. Its interesting to see the differences in functional requirements with the different sizes of projects in the formality guide, like seeing that in the rabbit size documentation isn't as necessary as it is in the elephant project where it is almost mandatory. Great job highlighting the definition of functional requirements as well.

    ReplyDelete
  4. Harvinder Singh24 April 2020 at 18:18

    Horse projects usually have a need to write their requirements in some communicable form. This separation might seem strange, as these requirements apply to an automated product. Keep in mind, however that you, as the business analyst, are not attempting to craft a technological solution, but rather to specify what that technological solution must do

    ReplyDelete

Post a Comment

Popular posts from this blog

Chapter 8 - Starting the Solution by Harvinder Singh

  Chapter 8 Starting the Solution We are transferring from an abstract global to the physical international, from policy to technology, from problem to solution; from purpose to design: we have reached the closing quadrant of the Brown Cow Model, in which will be determined how we are going to enforce the essential business. With a solid know-how of the essence of the business, which means that the real trouble to be solved, it’s time to determine which components of that problem would advantage from being automated. The commercial enterprise analyst juggles many factors to determine the most appropriate product to build. Iterative Development Iterative development is a way of breaking down the software improvement of a large application into smaller chunks. In iterative development, feature code is designed, developed and examined in repeated cycles. With each iteration, additional functions may be designed, advanced and examined till there is a com...
Read more

Chapter 4- Business Use Cases - posted by Chelsia Palta

Understanding the Work  The product you intend to build must improve its owner’s work; it will be installed in the owner’s area of business and will do part of the work. It does not matter which kind of work it is commercial, scientific, embedded real-time, manual, or automated you always have to understand it before you can decide which kind of product will best help with it. Use Cases and Their Scope The term "use case" was coined by Ivar Jacobson back in 1987 as a way to describe an interaction between a system and a user of that system. Jacobson needed to break the system into smaller units, as he felt that object models were not scalable. Thus, to conquer the complexity and largeness of modern systems, he said it was first necessary to partition them into convenient chunks, and that these chunks should be based on the user’s view of the system. The Outside World Adjacent systems behave like any other systems: They contain processes and consume and/or...
Read more

Chapter 11 Non-Functional Requirements by Hassan

Non-Functional Requirements Non-Functional Requirements can be generalized as "what a product/system is supposed to be. these requirements tend to be qualities that the product should have and they should specify how well the product does what it does. the requirements should either make the product usable, fast, reliable, attractive or safe and they should describe the character/ the way the functions should behave. Look and Feel Requirements the look and feel requirements are key to the non-functional requirements and as a BA one must consider them for every project. These requirements can describe how a product/system's desired appearance, mood, spirit or overall style/ appearance. The look and feel requirements can further specify what the product/system intends to appear as and is not a detailed design of the product/system itself. The typical look and feel requirement should be simple to use, professional looking, attractive to its market, consistent with previ...
Read more