GROUP@6

Writing the Requirements A major problem in system development is misunderstood requirements. To avoid any misunderstanding, the analysts must write their requirements in an unambiguous and testable manner, and at the same time ensure that the originating stakeholder understands and agrees with the written requirement before it is passed on to the developers. In other words, the analysts write the requirements so as to ensure that parties at either end of the development spectrum are able to have an identical understanding of what is needed. Although the task of writing down the requirements might seem an onerous burden, we have found it to be the most effective way to ensure that the essence of the requirement has been captured and communicated, and that the delivered product can be tested. The IceBreaker analysts start by writing their requirements using business language so that the nontechnical stakeholders can understand them and verify their correctness. They add a  ra...

Difference Between The Role of Sponsor And Customer The Customer will pay for the project’s product.  will give the products’ requirements and reap benefit from the product (usually long after the project is over).  may or may not be part of the Performing Organization. The Sponsor is usually part of the Performing Organization.  will decide how much funds will be used for the project. She/he will take budgetary decisions.  will appoint the Project Manager and provide necessary support to her/him.

Some of the performance requirements the BA should consider: Speed to complete a task The accuracy of the results  Safety to the operator  Volumes of data to be held by the product  Ranges of allowable values  Throughput, such as the rate of transactions  The efficiency of resource usage  Reliability, often expressed as the mean time between failures  Availability—the uptime or time periods when users can access the product  Fault tolerance and robustness  Scalability of most of the above

Project blastoff is a burst of activities to launch requirement project. The activities can include: kick off meeting, researching domains of interest, interviews, blogs, emails, conference and meetings. The blastoff defines the scope of the business problem and seeks concurrence from the stakeholders that this is the area of the owner's organization that needs to be improved. The blastoff meeting confirms the functionality to be included in the requirements discovery and the functionality that's excluded. Blastoff deliverables: Statement of purpose Scope of work Stakeholder list Project constraint Project goals Estimated cost Risks Glossary Go/No-go decision The blastoff has three crucial goals: 1. Study the business activity in which the product is to operate 2. Define the portion of work that will be carried out by the product 3. Identify all stakeholders

The Volere Requirements Process is the way to get you from the business problem all the way to atomic functional and non-functional requirements. Business Requirements are an essential part of project success and a key responsibility for the Business Analyst. A requirements something the product must do to support its owner's business, or a quality it must have to make it acceptable and attractive to the owner. A requirement exists because the type of product demands certain functions and qualities, or because the client asks for that requirement to be part of the delivered product. The most common objectives of the Business Requirements are: To gain agreement with stakeholders To provide a foundation to communicate to a technology service provider what the solution needs to do to satisfy the customer’s and business’ needs To describe what not how the customer/business needs will be met by the solution A key to complete and accurate requirements gathering i...

In this module, Roberson and Robertson stated eleven truths that are considered the essential contribution of requirements. Truth 4: There is an important difference between building a piece of software and solving a business problem. The former does not necessarily accomplish the latter. Many software development projects concentrate solely on the software. Most software projects manage to produce some software. However, concentrating almost exclusively on the software is a little like trying to build the Parthenon by  concentrating on stones. If the software is valuable to the owner, we must solve the business problem. The author usually refer to software; however, similar concepts can be applied to any output or product being built.