Need for paraphrase

Chapter 1

Knowing the requirements of a software application is a necessity for the success of that project. Since requirements are the basis for software development and project management activities, all stakeholders should participate in the requirements gathering process to achieve a high-quality product that satisfies all product users and benefactors.

According to Ian Sommerville and Pete Sawyer (1997). Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They maybe constraint on the development process of the system.

There are three levels of requirements: business requirements, user requirements, and functional requirements. First, business requirements answers the “why?” question. Why is this system being implemented, the benefits the organization is willing to achieve. Second, user requirements are the goals or tasks the user must be able to perform with the product. Third, functional requirements answers the “what” question, what are the behaviors the product will exhibit under specific conditions, what should the developers implement to enable the users to achieve their goals.

Product requirements defer from project requirements. Product requirements describe the properties of the software to be built, and it is usually written as a Software Requirement Specification (SRS) document, it is also the responsibility of the business analyst. However, project requirement are other requirement that are necessary to the completion of a software project, such as physical resources, training needs, legal protection, and many others, and it is the responsibility of the project manager.

Requirements engineering is divided into two sub categories: requirements development and requirements management. In requirements development process, we first perform elicitation activities that are gathering the requirements from the users by interviewing user, and making prototypes, developers can use either a usage-centric or product-centric approach elicitation. Next, analysis that is studying and deeply understanding the requirements gathered in the elicitation phase. After that, perform the specification phase that is documenting all of the requirements in a well-organized fashion (ex. Use SRS). Finally, validate the requirements by checking weather the documented requirements will enable the developers to build a solution that satisfies the business objectives. However, requirements management include a number of activities, such as defining the requirements baseline, keep track of changes made on the requirements, and much more. See the figure that shows the boundary between requirements development and requirement management.

There are some common requirements risks that may arise during the requirements engineering process, such as insufficient user involvement, inaccurate planning, creeping user requirements, ambiguous requirements, gold planting, and overlooked stakeholders.

Chapter 2

In software development process, there might be an expectation gap, which is a gulf between what customers really want and what developers deliver based on the requirements they took at the beginning of he project. This gap arises when there is not enough customer involvement with the developer. The ultimate solution for this problem is to have multiple contact points with the customer to reach a product with less expectation gap that is what the developer builds is very close to what the customer wants. Contact point can be of any form interviews, prototypes evaluation, requirements reviews, and much more.

A stakeholder is a person that is involved in the product outcome either internally or externally. However, a customer is an individual or organization that derives either direct or indirect benefit from a product. Also, user requirements should come from people who use the system directly or indirectly.

Since an excellent software product results from very good requirements that are usually the result of good interaction between the developer and customer, there are a number of rights and responsibilities for software customers that they need to pay attention for.

Customer’s rights are to expect the Business Analyst (BA) to speak their language, to learn about their business and their objectives, to record requirements in an appropriate form, to receive explanations of requirements practices and deliverables, to change requirements, to expect an environment of mutual respect, to hear ideas and alternatives for their requirements and their solution, to describe characteristics that will make the product easy to use, to hear about ways to adjust requirements to accelerate development through reuse, and to receive a system that meets their functional needs and quality expectations.

Customer’ responsibilities are to educate Bas and developers about their business, to dedicate the time that it takes to provide and clarify requirements, to be specific and precise when providing input about requirements, to make timely decisions about requirements when asked, to respect developer’s assessment of the cost and feasibility of requirements, to set realistic requirement priorities in collaboration with developers, to review requirements and evaluate prototypes, to establish acceptance criteria, to promptly communicate changes to the requirements, and to respect the requirements development process.

When a team works on requirement gathering, cultural clashes often arise on two types of team. There are people who identify the risks associated with working on software based on minimal requirements, and there are people who think requirements are pointless. Developers need to show those people that participation in product development is a necessary action that leads to the best in the entire project development.

In each project, the decision maker needs to be identified. The decision maker can be one person or a group that represent important areas, such as management, customers, business analysis, development, and marketing. The latter general works best.

The core of the customer-developer partnership is to reach an agreement on the requirements to be built resulting in a requirement baseline is a set of requirements that has been reviewed and agreed upon and serves as the basis for further development However, approving a set of requirements before starting developing is not the end of requirement management process. Requirements can change within the scope of the product being developed.

In agile projects, the product owner publicly accepts or rejects the requirements for an iteration, which consists of a set of stories.

Chapter 3

For a software project to succeed, software professionals need to have a variety of tool kits to gather requirements. However, the notion of best practices is debatable. For different project there are different sets of practices that are appropriate for understanding the requirements clearly.

The activities of requirements engineering –elicitation, analysis, specification, and validation- are interwoven, incremental, and iterative. In each process there are sets of good practices that can be followed.

In requirement elicitation, gathering business, user, and functional requirements. Some practices for requirement elicitation include defining product vision and project scope, identify user classes and their characteristics, select a product champion for each class, conduct focus groups with typical users, work with user representatives to identify user requirements, identify system events and responses, hold elicitation interviews, hold facilitated elicitation workshops, observe users performing their jobs, distribute questionnaires, perform document analysis, examine problem report of current systems for requirement ideas, and reuse existing requirements.

In requirement analysis, decompose high-level requirements into appropriate levels in detail, building prototypes, evaluating feasibility, and negotiating priorities. Practices in requirements analysis include model the application environment, create user interface and technical prototypes, analyze requirement feasibility, prioritize the requirements, create a data dictionary, model the requirements, analyze interfaces between your system and the outside world, and allocate requirements to subsystems.

In requirements specification, document the requirements in a consistent, accessible, and reviewable manner. Some requirement specification practices are adopt requirement document template, identify requirement origins, uniquely label each requirement, record business rules, and specify nonfunctional requirements.

In requirement validation, ensure that the requirements are correct and satisfy customer needs. Practices include review the requirement, test the requirement, define acceptance criteria, and simulate the requirements.

In requirement management, after the agreement on the initial requirements (baseline), developers must cope the changes customers may require during development. Practices in requirements management are establish a requirements change control process, perform impact analysis on requirements changes, establish baselines and control versions of requirements sets, maintain a history of requirements changes, track the status of each requirement, track requirements issues, and maintain a requirements traceability matrix.

In knowledge of requirements engineering, practices include train business analyst, educate stakeholders about requirements, educate developers about the application domain, define a requirements engineering process, and create a glossary.

In project management, the project manager should base project schedules, resources, and commitments on the requirements that are to be implemented. Good practices in project management are select an appropriate software development life cycles, plan requirements approach, estimate requirements effort, base project plans on requirements, identify requirements decision makers, renegotiate project commitments when requirements change, analyze, document, and manage requirements-related tasks, track the effort spent on requirements, and review lessons learned regarding requirements on other projects.

Chapter 4

The role of a business analyst (BA) in the development of a software project is critical and tough. He enables defining requirements and their solution in a way that all stakeholders are satisfied. His major role is to extract, analyze, document, and validate the requirements. He also assists in the communication between the customers and developers. A talented BA can see the signs of a good project and its success and bad one that will struggle from the beginning of the project.

The business analyst’s tasks are defining business requirements, plan the requirements approach, identify project stakeholders and user classes, gather requirements, analyze them, document them, communicate them, lead requirements validation, facilitate requirements prioritization, and manage requirements.

The skills a BA must have are listening skills, interviewing and questioning skills, thinking on your feet, analytical skills, systems thinking skills, learning skills, facilitation skills, leadership skills, observational skills, communication skills, organizational skills, modeling skills, interpersonal skills, and creativity.

The knowledge a Bas are recommended to have are knowledge of the business, the industry, and the organization. This knowledge is usually gained by experience and it is a powerful asset for an excellent BA.

The role of a BA on agile projects is usually done by a team member called the product owner, in which he will perform the traditional business analysis activities, define the product vision, communicates with all stakeholders, define the constraints, prioritize the software backlog of reaming work, and making the critical decisions about the product.

A BA can be a former user, a former developer or tester, a former (or concurrent) project manger, a subject matter expert, or a rookie. The following table presents each potential BA and what he can offer to the success of the project.

Potential BA	Advantage
Former User	He understands the business and the work environment, so he can gain the trust of his former colleagues, he speaks their language, and he knows the existing system and business processes.
Former Developer or Tester	Developers recognize the importance of the requirement process and some of them enjoy the communicating with customers to understand what they want. However, they also can easily lapse into technical thinking and jargons.
Former Project Manager	Project managers have some of the same skills as BA. They are used to work with teams, understand the organization and business domains, and shows strong communication skills. They are also good listeners, and negotiators.
Subject Matter Expert	SMEs can determine whether the requirements are reasonable, how they extend the existing system, how the purposed architecture should be designed, and the impact on users.

Chapter 5

Business requirements are defined as a set of information that is needed to lead a project to deliver a solution and the desired business outcome. Developers should not start any project without having a clear understanding of what will it add to the business. Also, they need to define the vision and scope of the project. The vision describes the ultimate product that will achieve the business objective, as well as, what the product is and what it could become. However, the scope identifies what portion of the product vision the iteration is developing, and it draws the boundary between what is in and what is out of the project.

The vision and scope document gathers all business requirements into one single deliverable that sets the stage for the subsequent development work. The following table shows the most important parts a vision and scope document might contain and their description.

Element	Description
1. Business Requirements
1.1. Background	Mention the history or situation that led to the decision to build the project.
1.2. Business Opportunity	Describe the business problem that is being solved.
1.3. Business Objectives	Summarize the business benefits the product will provide in a quantitative and measurable manner.
1.4. Success Metrics	Specify the indicators the stakeholders will use to define the success of the project. Identify the factors that have the greatest impact on achieving that success.
1.5. Vision Statement	Describes the long-term purpose and intent of the product and reflects a balanced view that will satisfy all stakeholders.
1.6. Business Risks	Summarize the business risks associated with the developing or not developing this product. They are not the same as project risks.
1.7. Business Assumptions	An assumption is a statement that is believed to be true in the absence of proof. Business assumptions are related to business requirements.
2. Scope and Limitations
2.1. Major Features	List the product major features emphasizing on those that distinguish it from previous or competing products.
2.2. Scope of Initial Release	Summarize the capabilities that are planned in the first release.
2.3. Scope of subsequent releases	If following an iterative development approach, build a release roadmap that indicates which functionality will be deferred and the desired timing of later releases.
2.4. Limitations and Exclusions	List any product capabilities that stakeholders might expect but that are not planned in a specific release.
3. Business Context
3.1. Stakeholder Profiles	Describes different categories of customers and other key stakeholders.
3.2. Project Priorities	To enable effective decision-making, the stakeholders must agree on the project’s priorities. One way to approach it is to consider the five dimensions of features, quality, schedule, cost, and staff.
3.3. Deployment Considerations	Summarize the information and activities that are needed to ensure an effective deployment of the solution into its operating environment.

There are many representations techniques of the scope such as context diagram, ecosystem map, feature tree, and event list.

Context diagram visually illustrates the boundaries and connection the scope establishes between the system being built and everything else in the universe. It identifies external entities (terminators) outside the system that interface to it n some way, as well as data, control, and material flows between the terminators and the system.

An ecosystem map represents all the systems related to the system of interest that interact with one another, it also represents the scope by showing all the systems that interconnect and therefore might need to be modified to accommodate your new system.

A feature tree is a visual description of the product’s features organized in logical groups, hierarchically subdividing each feature into further levels of detail. It provides a concise view of all of the features planned for a project.

An event list identifies external events that could trigger behavior in the system. It shows the scope boundary for the system by naming possible events trigged by users.

The business requirements and an understanding of how the customers will use the product provide tools for dealing with scope change. Scope change is not a bad thing if it helps you steer the project toward satisfying customers.

In agile projects, managing the scope takes a different approach. The scope of each iteration consists of user stories selected from a product backlog, based on their priority.

The project is complete when the success metrics indicate that you have a good chance of meeting the business objectives.