Business Requirements Report

Tags

requirements business application prelim...

Description

This is the report that assembles all the business requirements templates together.

You must be logged in to download this document

1 reviews

1 Business/User Requirements Date 2 Summary/Revisions Author Revision History Date Release Comments 3 Table of Contents ..................................................................................................... 1 Summary/Revisions .................................................................................................................... 2 Table of Contents....................................................................................................................... 3 Introduction................................................................................................................................ 4 Management Summary ............................................................................................................... 5 Signatures................................................................................................................................... 5 Requirements Analysis Process (The Method)........................................................................... 6 Business Requirement Document ............................................................................................... 7 Business Requirement Format .................................................................................................. 11 Business Requirements ............................................................................................................. 15 Requirement: Creating a Client File (Client Facet) .................................................................. 16 Requirement: Online Help Function......................................................................................... 17 Requirement: Bilingual System................................................................................................ 18 Requirement: Bilingual System................................................................................................ 18 APPENDICES .............................................................................................................................. 19 4 Introduction Describe the background information for this new project. What are the events that contributed to this new project? Goal /Purpose The goal of this exercise is to document the business needs and functionality of the target system. 5 Management Summary Client Organization Project Name Project Manager Start Date Completion Date Signatures Executives: ___________________________ Date: __________________ _________________________________ Date: ____________________ _________________________________ Date: __________________ _________________________________ Date: __________________ Project Manager: ___________________________ Date: __________________ 6 Requirements Analysis Process (The Method) Introduction The method used in the collection of business requirements is quite simple. It is a high-level process where the clients are interviewed and asked a few questions. This is also called the definition phase because we are mainly interested in defining the objects or functionality of a system. What we call Requirements Analysis is often referred to as Preliminary Analysis in some methodologies. The idea is to document it in such a way that the business people can easily understand without the need of getting an IT degree. This means that a combination of diagrams and mostly natural language will be used throughout this document. *** Note: Many experts claim that the Requirements Analysis phase is nothing more than an exploratory and self-correcting dialogue complete with stuttering, hemming and hawing, and Freudian slips. Out of that emerges a description for a product or system. The methodology is very rational and similar to our natural ways of learning. You can depict the process using a diagram. 7 Business Requirement Document The Business Requirement Document The Business Requirements are presented in a flexible report format that is normally managed by both the System Manager and the System Owners/Users. The document should contain the following sections: • Business Requirement Definitions and Specifications • Non-functional requirements • Conceptual System Models • Glossary • Appendices The business requirement (BR) document is the official business statement of what is required of the system developers or contractors. It includes both the definitions (and sometimes a detailed specification of those definitions). It answers the question “What should the system do?” rather than how it should do it. The “How it should do it” will be refined by the Systems Architect and the Programmer/Analyst. The BR phase should not worry about the “How To” questions at this stage – it should be avoided. Business Requirements Definition The business requirement definition is a statement written in a natural language that portrays one or more services delivered by a system (manual or automated). It is usually expressed in high-level terms/words/phrase easily understood by the system users, clients and managers i.e. written for the customers. Often, the Requirements Definition is referred to as the business functions, objectives or tasks. “What are the functions of a Case Manager? What do you do? What are your tasks?” People who are likely to read Requirements Definitions are the system enduseers the System Architect, the Employment Division managers, Case Managers or TED employees in general. Example of a Requirement Definition statement: “The software must be able to record or store general client information.” This statement could also be accompanied by data flow diagrams or other diagrams that the organization uses to describe processes and data relationships. Continued on next page 8 Business Requirement Document, Continued Business Specifications The Specification brings the definition to a much more detailed and perhaps technical. It is a detailed description of the BR definition (system service) described above. It is in more details because it serves as the basis for the next design or programming phase. They define the elements and constraints of the definition into a more technical specification of the end-product. Generally, IT shops will normally use forms in preparing systems specifications along with CASE tools and Functional Specifications. People who are likely to appreciate the specifications include the developers, the programmers, the System Architect, Functional Analyst and the system end-users. Example for the definition above: • Client last name and first name • Client address • Language of correspondence • Telephone and fax numbers • Client Identifier and Social Insurance number • The client will have to be classified in a number of ways. • This function will let us know how to contact the client • The client Identifier will be generated automatically as the case is created. • etc. Continued on next page 9 Business Requirement Document, Continued System Models In a Business Requirement or Preliminary Analysis document, it is generally accepted practice to define models showing system components and relationships. This is often done using drawing tools like VISIO, Business Process or CASE tools (like UML models). Systems models are often controlled by using a formal repository especially if the organization has a Enterprise Architecture (EA) Governance. In such cases, the models are treated as true enterprise assets. Non-Functional Requirements Sometimes requirements are specified more or less as constraints or as business rules and policies. These are known as non-functional since they really have nothing to do with the functionality of the software. Nonfuncttiona requirements define system properties and constraints like reliability, organizational language issues, response time, etc. Sometimes certain process requirements may even dictate the usage of a particular CASE tool like ER/BPWin. The process requirements are very important to understand. A system depends on both the data and the process aspects. Some non-functional requirements may be more critical than functional requirements because if some of those non-functional requirements are not met, the system becomes useless. Non-functional Classifications Non-functional requirements are generally classified as: • Product Requirements • Organizational Requirements • External Requirements Continued on next page 10 Business Requirement Document, Continued Product Requirements Those requirements that specify that the delivered product (software) shall behave in a certain manner. Examples of these are: response time, reliability criteria, Visual Basic language, etc… This type of requirement has nothing to do with the type of data or information we wish to process through the software. (We admit however that certain definitions could fall in gray areas and could be classified into many categories.) Organizational Requirement Those requirements that are the results or consequences of organizational policies, procedures and standards. Examples: bilingual policies, the delivery deadline … External Requirements Those requirements that define outside influences i.e. external to the system, organization and its development process. These requirements often deal with things such as environmental issues, legislative issues, safety and IT standards, linkages with other external systems, etc ... 11 Business Requirement Format Requirement Template Each requirement can be represented or described using the following format or form: Requirement Name: Requirement ID Number: Definition/Description: Type of Requirement: (Data Requirement, Information/Reporting Requirement, Nonfunctional Product Requirement, Nonfunctional Organizational Requirement, Nonfunctional External Requirement) Importance of Requirement: (From the business viewpoint. What is the impact of Excluding Requirement? What happens if we ignore this requirement?) Complexity of Requirement: (How complex is it to implement? An estimated value only. High, Medium, Low) Priority Level: (1 – Mandatory; 2 – Medium/Enhancement; 3-Optional) Application Fit: (How well does the application meet the requirement). Requirement Name The title or name of the requirement. About 2 to 5 words only. Requirement ID Number A number that uniquely identifies the requirement. Start with 01.00.00 and then go from there. It is for future references. If models exist then we could also use the model reference number. We could also include the Functional Spec number if that exists. Definition It is the description or the definition of the item or requirement as identified by the business users. It is a high level statement with sufficient details to convey the concept or the idea. It is usually expressed in a natural language and can be coupled with diagrams. Requirements should be written so that they : • convey the correct definition • are unambiguous (only one interpretation) • are complete • are consistent • are verifiable Continued on next page 12 Business Requirement Format, Continued Type of Requirement Requirements can be classified in a number of ways to ease the subsequent analytical steps and decisions regarding the importance to included a requirement in this current rollout or to include it in a subsequent enhancement project. As such, each requirement shall be classified as: • Data Requirement {Requirements can be stated in terms of the type of data that needs to be collected and stored. Example: for the entity Client Profile the attributes (data) are: name, address, education level, etc.} • Information/Reporting Requirement {Some requirement describe the type of information that is derived as a result of storing data and processing it. Information is a function of the data and the processes that affect it. Information is a resulting output of a system and usually takes the form of reports, letters, printed forms, queries etc.} • Nonfunctional Product Requirement {Product requirements are nonfuncttiona because they deal more with what the product might look like, and/or how the end product will behave. This requirement has nothing to do with the business functions but is more concerned with system/application qualities. Example: The system will be programmed in a GUI environment. The system will be programmed using VB.} • Nonfunctional Organizational Requirement {The requirements, policies, rules and regulations that the organization imposes on the system delivery. Example: the system must meet government security policies and standards.} • Nonfunctional External Requirement {Requirement that are generated outside of the organization or system functionality. Often regulatory, environmental or connectivity to outside systems and organizations. Example: the system must integrate with a supplier’s database.} Importance Justification The business stakeholder will describe the reason why they feel the requirement is important for the bottom line. Often they will express a goal, an objective or the contribution to the organizational mission. Describe what will happen if we fail to implement a given requirement. How will it impact the software and the business unit if we do not include the requirement? The idea here is to explain the importance of having the requirement -the impact on the overall project and organization. Continued on next page 13 Business Requirement Format, Continued Complexity of Requirement How hard will it be to implement this requirement? Is it a major undertaking? How much effort in terms of time and resources? What are the risks? (Sometimes a requirement can point to a whole new separate project or enhancement.) Complexity can be classified as: 1. High (The implementation of a requirement has a direct impact on project deadlines and functionality. Very complex and costly to implement. Usually anything that affects the strategic application architecture is complex. Sometimes, very complex functionality that be treated as a separate project or service. As a rule of thumb, anything that would take a few weeks or so to develop is probably high complexity.) 2. Medium (The medium complexity is something that would take a few days of development time. Could be treated as a later enhancement to the product.) 3. Low (The low complexity is something that could be implemented within a couple of days. ) ** In this preliminary/requirements stage, complexity is nothing more than a rough estimate based on the analyst’s experience. Priority Level The priority is expressed from a business viewpoint. Requirements can be given a priority over others and could be classified using the following scale: 1. Top Mandatory (Requirements that absolutely have to be implemented otherwise the product is useless. A requirement that must be implemented no matter what. A product that meets mandatory requirements will satisfy customer needs.) 2. Medium/Enhancement (An enhancement is an important requirement that will contribute to the overall mission/objectives. However, because of time, money and resources constraints, it would be better to include it in a future enhancement of the product. Omission of this requirement will not jeopardize the functionality or success of the product.) 3. Low/Optional (This is a non-contributing functionality of the product. Example: the ability to save in a Word Perfect format – nice to have but certainly not necessary. Requirements that are optional or non-essential do not impact the success of the application because it does not directly contribute to the functionality of the product. ) 14 Application Fit This is to determine whether the candidate applications and their functionality really meet the business requirement. This is actually the basis of “Fit-Gap Analysis” or what many Analysts call an “Application Function to Requirements Matrix”. The purpose here is to determine how well a given requirement has been met by one or more applications or proposed alternatives/solutions. It is merely a qualitative guesstimated measurement expressed in percentages (or whatever scales the analysts decides). The scale might look like: 100% = The application meets or exceeds the requirements 0% = The application does not meet the requirements Any other figure like 75% would mean that the application meets most of the requirements but must be improved. A figure less than 100% should catch the Analyst’s eye especially if it is a “Mandatory” requirement. 15 Business Requirements Intro The following requirements were identified and documented by the Requirements Working Group. The group had the mandate to identify the requirements for a new application ….. 16 Requirement: Creating a Client File (Client Facet) Reference ID 1.00.00 Definition This is a functional requirement of the proposed case management system. The system must be programmed with the ability to store client tombstone data information. Essentially, this function deals mainly with the storage of client data attributes that falls in three sections or entities: Personal Info Entity (name, address, gender, language etc.) Education Data Entity(Education certificates, degrees, etc) Employment History Entity (Employer name, address, telephone etc) Importance Justification Like many other apps, tombstone information is mandatory. Data collection at the Client Information screens must be recorded to aid the counselors is assessing client needs. Once the basic client information is collected the user can then move to next phase (screen) of collecting information for the counseling procedures. Data Information/Report Process Nonfuncttiona Product Nonfuncttiona Organization Nonfuncttiona External Type of Requirement X Complexity High Medium X Low Priority Mandatory X Medium/Enhance Optional Application Fit Current App: 100 Alternate 1: 100 Alternate 2: 60 (The Application fit above indicates that the current production application meet all of the requirement. The “Alternate 1” application or solution meets all the requirements too whereas the “Alternate 2” solution only meets about 60% of the business requirement.) 17 Requirement: Online Help Function Reference ID 12.02.00 Definition Users would like to see a system with a good HELP function built-in. For example, they would like to have a hot key (i.e. F1) programmed with Help documents. The Help Document should also be available for printing or viewing outside of the application. The Help Function in Alternate 1 is very well designed and quite exhaustive. A lot of emphasis was put on Helps during the design of Alternate 1. Importance Justification Help in doing things inside an application is an important functionality. Data Information/Report Process Nonfuncttiona Product Nonfuncttiona Organization Nonfuncttiona External Type of Requirement X Complexity High Medium X Low Priority Mandatory X Medium/Enhance Optional Application Fit Current App: 0 Alternate 1: 100 Alternate 2: 50 (The Application fit above indicates that the current production application has no Help feature and therefore it must be programmed from scratch. The “Alternate 1” application or solution meets all the requirements for the Help feature whereas the “Alternate 2” solution only meets about 50% of the business requirement.) 18 Requirement: Bilingual System Reference ID 12.17.00 Definition Users have asked that the system be able to switch easily from an “english” interface to a “french” interface and vice-versa. The system must be able to satisfy both official languages. Importance Justification The Government policy specifies that any new development effort or system acquisition should emphasize the bilingual services/characteristics of the Province. Services must be delivered in both official languages. The developers should pay special attention to the actual wording and terms used throughout the system. Straight translation is often unforgiving of context. Data Information/Report Process Nonfuncttiona Product Nonfuncttiona Organization Nonfuncttiona External Type of Requirement X X X Complexity High Medium X Low Priority Mandatory X Medium/Enhance Optional Application Fit Current App: 60 Alternate 1: 75 Alternate 2: 0 (The “Alternate 2” solution does not have bilingual capabilities. The “Alternate 1” solution needs to be enhanced in order to meet requirement. ) 19 APPENDICES