1 / 18

Bite sized training sessions: Business And Functional Requirements

Bite sized training sessions: Business And Functional Requirements. Objectives. To understand What business and functional requirements are The difference between them Where they come from Where they fit in to analysis The importance of business and functional requirements To be able to

johnda
Download Presentation

Bite sized training sessions: Business And Functional Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Bite sized training sessions:Business And Functional Requirements

  2. Objectives To understand What business and functional requirements are The difference between them Where they come from Where they fit in to analysis The importance of business and functional requirements To be able to Discover business and functional requirements Document business and functional requirements

  3. Chain Of Reasoning: Change Requirements must be assumed to be wrong until they are provedto be right Stakeholders

  4. What are Requirements? IEEE Definition 1. a condition or capability needed by a user to solve a problem or achieve an objective2. a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document3. a documented representation of a condition or capability as in (1) or (2)

  5. What are Requirements? ISEB have 7 types of requirement: • General Requirement • Business Requirement • Functional Requirement • Detailed Requirement • Non-functional Requirement • Data Requirement • Technical Requirement

  6. What are Requirements? IIBA have 6 types of requirement: • Business Requirements. • User Requirements • Functional Requirements • Quality of Service Requirements • Assumptions and constraints • Implementation requirements.

  7. What are Requirements? A pragmatic ‘definition’ Requirements are the answers to the question: “what will this project change that is required in order to deliver the objectives?” “change” can be create, update or delete something The focus is on “what will change” not “how will it change”. Question: Is there a material difference between business and functional requirements?

  8. Requirements Levels Business & functional requirements are high level requirements …e.g. “be able to take orders” Process and data models are low level requirements - rules …e.g. “customers have to register before placing orders” as seen in Data and Process modelling sessions

  9. Functional Requirements Examples • The solution will automatically validate customers against the ABC Contact Management System • The solution will enable users to record customers sales • The solution will enable Customer Order Fulfilment letters to be automatically sent to the warehouse. Question: What does “solution” mean in this context?

  10. Best practice • Document requirements, not physical solutions! • Document one requirement at a time! • Map each requirement to the objective(s) and/or principle(s) it contributes to delivering. • Make each requirement as complete and accurate as it needs to be to answer the question “what does the solution need to change in order to deliver the requirements?”. • If there is a known, verified constraint that materially affects a requirement, then state it.

  11. Examples of poor functional requirements • Be able to use diary functionality • Be able to flag premium customers • Be able to track and report on sales • Increase accuracy of sales information • Allow authorised users of team-leader and above to cancel sales orders • Prompt the owner of the sales order to notify the customer of cancelled sales orders.

  12. Common mistakes • Designing the solution • Unjustified requirements • Putting in unjustified extra information • Not putting sufficient detail in • Protecting requirements – ego fuelled analysis!

  13. Functional Requirement Prioritisation - MoSCoW • Must have requirement • o • Should have requirement • Could have requirement • o • Wish list requirement

  14. Functional Requirement Prioritisation Logic • Must have: the project objectives cannot be met without this requirement • Should have: the project objectives can be met without this requirement but not as well as with it • Could have: this requirement only maps to one or more principles • Wish list: this requirement does not map to any project objectives or principles.

  15. Functional Requirement – where do they come from? • Declared by Stakeholders • Interviews • Workshops • ‘Casual’ communications • Constraining standards and procedures • Documents • Interviews • workshops • Proposed byBusiness Analysts! • All the time • Any way that is needed.

  16. Exercise: Document some functional requirements • Using the Objectives you analysed, define some functional requirements • Map which objectives and/or principles they contribute to • Prioritise them • If you need to make any assumptions, document them. • Time allowed: 20 minutes • Deliverable: Flip chart list of requirements

  17. Questions?

More Related