GROUP@6

Non-functional requirements: The non-functional requirements explain that how well the product does the things which it was supposed to do. If the business analysts do not pay attention to these requirements, then the product produced by their team will be inconvenient and impossible to use. The types of non-functional requirements are given below: 1.       Look and feel: It is about the appearance of the product 2.       Usability and humanity: These requirements explain how easy the product is to use, and how it can make the user’s experience better 3.       Performance: These requirements are about how fast, accurate and safely the product works 4.       Operational: These requirements mention if any specific environment is needed for operating the product 5.       Maintainability and Support: These requirements are about any kind of support or the...

Non-Functional Business Requirements describe the look and feel of the product. Since it can be subjective to individual taste, it is recommended that the BA try to be as specific as possible. The Non-Functional Requirements describe the qualitative behavior, or the “how well” qualities, of the product—whether it has to be fast, or safe, or attractive, and so on. These qualities come about because of the functions that the product is required to carry out.   Examples of non-functional requirements: "Approachable –no hesitation to use" could describe a website where the information is very clear to the user and there is no doubt on where the user should click when the user first accesses the website.   Some other examples of Look and Feel requirements: Simple to use Approachable –no hesitation to use it Professional looking Authoritative –trustworthy Attractive to the target group Consistent with the client's other products. Innovative and ...

The functional requirements describe the product’s processing—the things it has to do to support and enable the business. The functional requirements should be a complete and, as far as possible, unambiguous description of the product’s functionality. The functional requirements are derived from the product use cases. The most convenient way we have found to generate the functional requirements is to write a scenario that breaks the product use case into between three and ten steps. Examine each of the steps and ask, “What does the product have to do to accomplish this step?” The things that it does are the functional requirements. We suggest that you write these requirements (for the moment) using two components: a description and a rationale. 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 f...

Brown Cow Model How Now : It specifically focuses on how a company is organized. The organizational chart demonstrates the employees, their job title, their responsibly and their accountability. What Now : It is in the left upper quadrant of brown cow model. This dynamic view is just worried about what must be finished not with standing how it is structured or actualized. What Future : After watching the now conditions, it is the time to look for the future. In What Future, we focus on the future opportunities for the organization. How Future : It is the last and lower right quadrant of the brown cow model. This view centers around how we will take care of the issue, execute the new framework, roll out the improvement.

Project Blastoff Project Blastoff mainly occurs when all the stakeholders come together to discuss about the project’s ·         Risks ·         Future outcomes ·         Cost ·         Scope ·         Domains interest Difference between sponsor and customer Sponsors are those who pays or make expense for the project up to its completion. It can be a single person, or it can be an organization who sponsor for a product or project Customers always pays for the final product or service they are getting after production and completion. Example: They just pay for the products which are displayed, or which are being advertised by the manufacturer or retailer.

Functional Requirements Functional requirements specify the needs that the product must meet if it is going to be useful to its operator and these needs are raised by the stakeholders. It is important to gather the functional requirements because it gives an idea to the business analyst about the necessary functionality of the product. It helps him in explaining to the developers that what they are going to do and what company is expecting from them. The functionality of the product is usually determined by business analysts during trawling and while making the scenarios. The main objective of writing these requirements gives a clear idea to the developers to build the exact product that the client is looking for and the actor needs to do the work. Technological Requirements It is the functionality which is purely needed based on the technology chosen. These requirements are not for business purposes, but they are for making chosen implementation work. Usually, they are recor...

There is no formulaic method for arriving at the optimal solution; you have  lots of factors to juggle, and the best design is simply the best compromise among all of them. Your task is to put together the best set of compromises to make the optimally valuable product. You are being pulled in multiple directions. One direction is functionality, and generally speaking, the more functionality you automate, the greater the benefits. Naturally enough, the cost of development is pulling in exactly the opposite direction. Another direction is differentiation. Differentiation does not mean just being different—you could use a different color and that would be different, but not particularly beneficial. Instead, differentiation means establishing a clear separation between your solution and any others, having an end product that represents a distinct leap forward. Generally, the more differentiated your product is, the higher the benefit it brings. Your solution should be inno...

Brown- Cow model: Brown-Cow model is basically used for analyzing the work area and there are many possible ways in which we can investigate it. The major and useful ones are: 1.       How Now 2.       What Now 3.       Future What 4.       Future How How Now: Mostly it is the first place to start and includes mentioning what already exists such as physical artifacts, equipment, and staff. What Now: It is concerned with understanding the business data, business policies, and rules and figure out what their current business is doing what they have to do regardless of how it is going to be implemented. Future What: This view is about finding where innovation can take place and how they can make their business policies better which will benefit their business. Future How: This view focuses on what could be the solutions to the current problem, how these solutions...

Help shareholders identify the real problem and address real issues (not what they think the real issues are). When this is done correctly, there is less re-work done as there won't be a need to make changes to the agreed upon initial solution. Thinking above the line with Brown Model to remove technology and find the true essence of the business Deliver the right product and solve the right problem Personas:  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. We strongly suggest using a persona when you do not have access to the real users or customers. Almost always, the persona is a better representation of the user than a human proxy. Challenge constrains and innovation workshops Brainstorming

Scenarios is an outline of the work in three to ten steps in logical order to explain what is going to be done. It helps to define a Business Use Case.  Scenarios are useful in most situations—anyone can understand them, and they fit into every development style.  A business analyst would use a scenario describe a business use case to its interested stakeholders. The BUC is a discrete amount of functionality; it happens in its own time frame, and can be considered separately from other parts of the work’s functionality.  Diagramming the Scenario Some requirements analysts stakeholders prefer to use a diagram to explain the functionality of a BUC. This preference is a matter of personal choice, and it depends largely on whether your audience responds more favorably to text or to diagrammatic scenarios Several diagrams can be used for scenarios. The UML (Unified Modeling Language) activity diagram is a popular choice

Interviewing the Stakeholders:  Interviewing the stakeholders is a technique that is commonly employed, but is not without its problems. The interviewer relies on the interviewee to know and be able to verbalize all the necessary knowledge about the work. This method may work very well when people are familiar with the work, but that knowledge is often restricted to their own immediate area. There are likely to be few people in the organization who understand enough of the business to be the sole person to describe it for you. Interviewing also requires some abstraction and communication ability on the part of the interviewee. For this reason, it is wise to avoid relying on interviews as your sole method of gathering requirements; instead, use them in conjunction with other techniques. Some requirements analysts draw up a questionnaire and send it to the stakeholder in advance of the interview. While this preparatory step gives some structure to the subsequent interview, we...

Module 3-1 Business Use Case  The BAs should develop Business Use Cases as they help them improve communication among team members. It can encourage common agreement about work requirements and reveal process alternatives. The BUC separate what belongs inside and outside of the project scope. The Product Use case is derived from the Business Use Case. It describes and documents the optimal product functionality. The part of the Business Use case that the BA agree will be carried out by the product. Module 3-2 Trawling for Requirements Once the blastoff is completed, the BA start trawling the work to learn and understand its functionality. The responsibility of the BA is to talk to people to understand what they say and what they don't, determine what they need and learn from the people who do the work. Trawling means discovering the requirements. The BA sit with the IceBreaker technicians as they describe the work they currently do and their aspirations for work the ho...