Skip to main content

Posts

Showing posts from November, 2018

Usability Requirements

Usability Requirements Ease of Use Requirements: This requirement deals with the aspect to make the product usable for the user. The product should have the following properties for the ease of use Efficiency of Use  Ease of remembering    Overall satisfaction Feedback Personalization and Internationizational Requirements: These requirements deal with the way the product can be changed or advanced related to the user's choices or preferences. The product could have the following personalized requirements: Language or spelling preferences Currency choices Personal Configuration options Learning Requirements: These consider how easy it is to learn to use the product or the service. These requirements may differ on the level of technology or any advancement involved in the product. Some services also require for the engineers or the user to train in a specific program to be able to efficiently use the service or the product. Understandability and Politeness Requiremen

Chapter 11 (Harpreet Singh Brar)

Non- functional requirements Non- functional requirements are properties that the functionality must have. The functionality can be represented either by a product use case or its constituent functional requirements. The eight major non-functional requirements for this product use case in chapter 11 are: 1   Look and Feel requirements 2   Performance requirements 3   Maintainability requirements 4    Operational requirements 5     Legal requirements 6    Security requirements     Political requirements 8     Usability requirements Cultural Requirements Cultural requirements specify special factors that would make the product unacceptable because of customs, religion, languages, prejudices, or almost any other aspect of human behavior. These requirements are necessary when we try to sell a product into a different country or in another culture.

Avoiding Ambiguity

In a business context, Ambiguity means doubtfulness of meaning, or uncertainty of intention, that makes a document capable of being understood in two or more senses. It is very necessary for any business to avoid any sort of misunderstandings that may occur due to such ambiguity. Ambiguity while writing requirements is can arise usually and it is very important to be avoided. But before sorting ambiguity, it is essential to understand why or how ambiguity occurs in any business case. The first reason can be the English language. English is a very vast language and can have several meanings for the same word. Such homonyms can lead to many confusing situations if the meaning is misinterpreted by the stakeholder. It is normally suggested to read the requirement or the sentence situation out loud before presenting it to the stakeholders. And after this, communicating with the stakeholder if they are on the same page and understand the meaning we wish them to know, can be helpful to es

Exceptions & Alternatives and Technological Requirements (Harpreet Singh Brar)

Exceptions and Alternatives Exceptions are the unwanted variations but inevitable deviations from the normal case caused by errors of processing and incorrect actions. For example -   The things we don’t want to happen in the project. Alternatives are the allowable variations from the normal case. Alternatives might be considered as the second-best solution for the any kind of work.   For example -   Things we want as our backup in the project. Technological Requirements Technical requirements pertain to the technical aspects that our system must fulfill. Technological requirements are functionality that is needed purely because of the technology chosen by the company to carry out projects. Technological requirements are not there for business reasons, but rather to make the chosen implementation work. Stakeholders must understand clearly why a requirement appears in the specification, so it is important that the technological requirements are not introduced before the

How should the BA handle the current organizational division of work

The BA can begin the process of defining, articulating, and communicating project success criteria as soon as he/she has a strong involvement in the requirements process and familiarity with the product and the project context.  The attempt to define what kind of compensation between competing demands the stakeholders are willing to accept are much more important project success criteria than if the project should be delivered on time, and within budget and with complete specifications. Some people argue that the definition of success criteria is the project manager role; however, BAs can carry out this task - because some have the experience and knowledge to develop this activity.  Ideally, all stakeholder analysis should be carried out jointly between BA and PM. In fact, this is a more efficient and effective use for the success of the knowledge project that BA has already achieved. The BA can play an important role by acting as an "deputy PM". Ha

The Brown Cow Model in Agile

There are reports stating, “agile does not help in innovation”. As there is a pressure to develop anything, they can produce within the time allowed. The greatest pressure is for maintaining the speed of the project, not for its innovative solutions. When we talk about innovation it means new thinking. We do not mean that innovation is invention. Innovation is different thinking about the business problem with the intention of finding beneficial solutions. User stories that are not based on real business stories will always have a hard time being innovative. Without some innovative thinking, it is very easy to propose only that you increment something and let it go through it. When a BA investigates a business history, this professional needs to be purposely trying to encourage innovation. The Brown Cow Model illustrates the ability to analyze the same business history from several different points of view. From there, innovations are discovered t

Personas and Innovation Workshops (Harpreet Singh Brar)

                                                 Persona A persona is an invented personality, an imaginary but nevertheless typical user or customer for whom you are gathering requirements for your product. Personas are useful when real users are not available or are too numerous for you to interview all of them, The persona is a virtual character that substitutes for the human users. Almost always, the persona is a better representation of the user than a human proxy.                                                  Innovation Workshops Innovation workshops are one way of generating ideas. Innovation workshops are mostly used when a large number of stakeholders are involved in the innovation process. Best use of these workshops are made when you want to show the advantages of developing a new and better way of working to the stakeholders instead of just rebuilding the same old system.

The Brown Cow Model

This model of work has four views of work which are What, Now, How and Future. The two horizontal and the vertical axes separate What from How, and Now from the Future. The Brown Cow Model illustrates four points of view that help to uncover the real business problem and identify useful innovations. The four quadrants which are - What-Now, What-Future, How-Now, and How-Future show the different viewpoints of work. Generally, it is not sufficient to have only two views of business - the "as is" and the "to be". To get a true light on the business problem and to ensure innovations, more views are necessary. Aziz

Time-triggered business events and Actors (Harpreet Singh Brar)

Time – triggered business events are initiated by the arrival of predetermined time or date. A time-triggered business event happens when a prearranged time is reached. This is based on either a periodic occurrence, fixed time interval, or a certain amount of time elapsing since another business event. For example – A computer system checks the available memory 2.4 microseconds after the last time it checked.                                                                             Actors  When the product use case is determined, there should always be some Actors who interact with the product. Actors are the people or systems that interact with the automated product or sometimes are the adjacent systems that are outside the work, more clearly like the organization’s customers. Actors are involved in every product use case and the product’s boundary. Different notations are being used for actors according to the way in which they interact with the product.

Some Stakeholders

The customer The  customer  buys the product  as soon as   it's far   advanced ,  turning into  the product’s new  owner .  to influence  the  customer  to  purchase  the product,  you need to   construct   something  that your  client  will  locate precious  and  useful  and  enjoyable . Where  many  capability   clients  exist, you  need to   find a   manner  of representing them  for your   mission . This  representation  can come from the  advertising   branch , senior  users  from one or  greater  of your key  clients , or a  mixture  of  area   and usefulness   professionals  from  inside  your  agency . The Sponsor T he sponsor pays for the development of the product. At the   easy   basis  that “ money speaks ,” the sponsor,  by way of   deciding to buy  the  development , has the  very last say in what that product does,  how it  does it,  and the way   problematic  or how sparse it  ought to  be. In  other phrases , the sponsor is the  final  arbiter of which p