Scotiabank

Look and Feel Requirements These requirements are related to look, style or behaviour of any specific product and impression  the user gets when using that product. For example, it can be colour, size , design of product and how user feel about it such as impression user gets when using the product. The rationale for this requirement is either attachment to branding standards or a desire to enhance customer recognition. In addition, fit criterion will be specify target that is easily determine when you know the rationale. Usability and Humanity Requirements Usability and Humanity Requirements involve the experience of users when using the product. For example, users can find that product is easy to use or hard to use, able to use by certain kind of users only. So, all things are relate to user's experience about a product. We should specify a target for who will be going to use it the most as it can be specific age group or for people how have disabilities. So, these requirem

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

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

  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 complet

According to chapter 7 of the Mastering the requirements process book, it is important to get the real problem by using abstraction – focusing on ideas rather than solutions.   That is, abstraction involves thinking about the essence of the subject by discarding the technological and physical components. The Brown Cow Model:   Thinking above the line   It is time to move above the horizontal line and go to the “What” section, where you can see the real business (essence of the business) without considering the solution.   Once you see that, you move to what you would like to be doing in the future (what-now and Future-what quadrants).   The reason for spending time above the line is to discover the real problem and avoid building solutions to the wrong problems.   So, the requirements discover task is to interpret what the stakeholder is saying and uncover its essence. Swim Lanes Begone It is about adding swim lanes to represent process models.   This is a way that busine

Formality guide Rabbit: Within rabbit projects, teams are most likely to view the work to be done in smaller slices. Teams will have to understand the work that is in front of them and understand the work that must be done thoroughly. Rabbit projects require minimal stakeholders and documentation. the process in rabbit projects is based on a cycle that repeats itself. Horse: Horse projects will definitely have more stakeholders and will require much more documentation. These projects usually dive into the critical infrastructure systems so understanding the work and the knowledge of the work is very important. Horse projects make good use of Apprenticing, interviewing and use case workshops. Elephant: Elephant projects have a very large number of stakeholders and because of this it is important to have a good knowledge and understanding of the goals and the work of the project. Elephant projects require trawling due to the high number of stakeholders and documentation during

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

Chapter 6 - Scenarios At this stage of the requirements process, the business events were identified, and thereby the business use cases (BUCs) that respond to the events. The scenarios must be used to model and record the BUCs, as they are very effective, largely because of their ready acceptance by nontechnical stakeholders. Formality Guide Scenarios are useful in most situations, e can understand them, and they fit into any development style, but projects will have different needs related to their size. Let’s have a look on these three projects: ·         Rabbit projects can use scenarios as a trawling technique, discover the required functionality by working with scenarios. Rabbit scenarios usually overlook non-functional requirements and capture them later by writing separate non-functional story cards. ·         Horse projects might consider scenarios as an alternative to writing atomic functional requirements. For complex products or if you need the