Paul Ramsey – 8 June 2006 – inaugural mtg IIBA BABOK globally recognized standard for practice of business analysis. framework describes business analysis tasks that must be performed in order to understand how a solution will deliver value to the sponsoring organization.” global standard value of standard: save time, improve the quality of work AND easier to communicate with others using same standard
move along gradient as needed context – org, product
consider options
consider options
Requirements engineering refers to all the activities involved in discovering, detailing, testing, documenting and maintaining software requirements. It includes the activities involved in understanding the business needs and transforming those into requirements that are allocated to software. There two sets of activities: requirements development and requirements management. Requirement engineering involves both development and management of requirements. Development of requirements involves much human interaction, investigation and discovery. Models can be text, visual, or a combination of both. Models communicate the requirements needed. Requirements management establishes and maintains an infrastructure for requirements, which allows for change, and establishes practices that ensure that the right software is being developed (validation) and that it is being built correctly (verification). Managing requirements is more technical and mechanical, although some of the management activities, such as change control and re-prioritizing requirements, require direct and heavy customer interaction. Note : Requirements engineering in the software industry does not address the business requirements that are not allocated to software. Those need to be owned and managed by the business (see the “Business Change Document” template in your Appendix). New or changed software results in changes for people and processes. For example, operational timings, steps, business rules and roles often change as a result of software implementation. How those changes are communicated and documented, how and when users are trained, and how and when business results are measured must be the responsibility of the business customer. This is often ignored (or addressed too late) in software projects. It is an element, however, which will make or break the success of a project.