Business Analysis Notes - Requriments-on-engr-analysis-project/future-sponsor-project GitHub Wiki

Business Requirements Specification (BRS)

BRS is the initial specification set by the client for the product being developed.

Reading Notes

https://requirements.com/Content/What-is/what-are-business-requirements-1

https://www.bridging-the-gap.com/business-analysis-process/

https://visuresolutions.com/blog/requirements-specification/

Ch1 notes

The definition of a requirement is a description of how a system should behave. They are a description of what should be implemented and maybe constraints.

A business requirement is a high-level business objective of the producer

An external interface requirement is a description of a connection between the software and a user, or another software and of hardware

A functional requirement is a description of behavior the system will exhibit under certain conditions

A nonfunctional requirement is a description of a property or characteristic that the system must exbibit a constraint

A System requirement is a top-level requirement for a product that contains many subsystems

A User requirement A goal or task that specific classes of users must be able to perform with a system, or a desired product attribute.

A Quality attribute is A kind of nonfunctional requirement that describes a service or performance characteristic of a product.

A Feature One or more logically related system capabilities that provide value to a user and are described by a set of functional requirements

A Constraint A restriction that is imposed on the choices available to the developer for the design and construction of a product

A Business rule A policy, guideline, standard, or regulation that defines or constrains some aspect of the business. Not a software requirement, but the origin of several types of software requirements.

The three requirement documents are Vision and Scope Document, User Requirements Document, Software Requirements Specification

A constraint on the development of the software (for example, “The software shall be developed using a RUP process”) is called a process requirement.

Other expectations and deliverables that are not a part of the software the team implements, but that are necessary to the successful completion of the project are called project requirements

The process of making requirements is called requirements engineering and it can subdivide into requirements development and requirements management. Finally, requirements development can be subdivided into four more categories elicitation, analysis, specification, validation

Elicitation is involved with finding requirements

The analysis involves understanding the requirements

Specification involves storing requirements

Validation involves confirming requirements

The main requirements risk is insufficient user involvement, inaccurate planning, creeping user requirements, ambiguous requirements, gold platting (adding things not mentioned or wanted but the developer thinks will be good), and overlooked shareholders

CH 3 notes

The main steps for finding and using business requirements are Define user requirements, identify user lasses, identify user representatives, identify requirements decision makers, plan elicitation, identify user requirements, prioritize user requirements, flesh out user requirements, derive functional requirements, model requirements, specify nonfunctional requirements, review requirements, develop prototypes, develop architecture, allocate requirements to components, validate user requirements.

List of good business practices on pages 48-57

CH 4 notes

A Business analyst is not really a job but more of a project role

A business analyst must define business requirements, plan the requirements approach, identify project stakeholder and user classes, analyze requirements, elicit requirements, communicate requirements, lead requirements validation, facilitate requirements prioritization, manage requirements

My Business Analysis

I researched various methods of creating business requirements and looked up some already-made business requirements to get an idea of how my requirements should look like and how they should be formatted.