Inggang Perwangsa Nuralam, SE., MBA.

Transcription

1 Inggang Perwangsa Nuralam, SE., MBA.

2 1. THE PROBLEMS WITH REQUIREMENTS FACTS of PROBLEMS: 1. Over 80% errors are introduced at the requirements analysis stage. 2. Less than 10% errors are introduced at the development stage. 3. Most of the project time is allocated to the development and testing phases of the project. 4. Less than 12% of the project time is allocated to the requirements analysis phase. 5. There is poor alignment of the developed system to business strategy and objectives 6. There is poor requirements management.

3 1. THE PROBLEMS WITH REQUIREMENTS Typical problems with requirements have been identified as: Lack of relevance to the objectives of the project; Lack of clarity in the wording; Ambiguity; Duplication and conflicts between requirements; Requirements that assume a solution rather than stating what is to be delivered by the system; Uncertainty amongst business users about what they need from the new system; Inconsistent levels of detail.

4 1. THE PROBLEMS WITH REQUIREMENTS Defining the requirements understands the objectives, scope and constraints within which the project (OSCAR): Objectives: of which both business and project objectives should be defined; Scope: the aspects to be covered; the activities and deliverables of the project. Constraints: the budget, timescale and standards of the projects Authority: the business authority for the project, ensuring that there is an ultimate arbiter to handle any conflicts between business users and their requirements; Resources: the people and equipment available to the project.

5 1. THE PROBLEMS WITH REQUIREMENTS The business analyst is the person who must help the staff members visualise precisely what they need the new system to do, and then help them to articulate this. Difficulties for the business analyst is recognising the different stakeholder viewpoints. Depending upon their roles in the organisation (one might see the business system interm of product, marketing, or customer focused. The analyst or requirements engineer needs to understand all of these valid perspectives each is a Weltanschauung.

6 2. A PROCESS FOR REQUIREMENTS ENGINEERING Requirements elicitation Requirements analysis Requirements validation Requirements documentation Requirements management

7 3. REQUIREMENTS ELICITATION Requirements elicitation is concerned with gathering information and requirements from the business stakeholders. Individual Corporate Tacit Knowledge Skills, values, taken-forgranted knowledge, intuitiveness Norms, back story, culture, communities of practice, organisation history Explicit Knowledge Task definitions, job descriptions, targets, volumes and frequencies Procedures, style guides, processes, knowledge sharing repositories, manuals, company reports Tacit Apprentice (shadowing); Observe; Recount (scenarios); Enact (prototyping) Report and record Disseminate Explicit

8 3. REQUIREMENTS ELICITATION BUILDING THE REQUIREMENTS LIST The requirements list is quite simply what it says a list containing every requirement that has been stated or elicited. The list tends to be an informal document and can be presented using three columns. Requirement Source Comments The company needs to reduce the amount of paper moved between departments. The system must capture customer payments. I. Morris Real requirement? See 5, as well I. Morris The customer file must be password protected. F. Drake Non-functional? Is this a We need the information quicker J. Keen Quantify what information? What timescale? What is wrong with current? We must record customer details, and be able to amend them and delete old customers. J. Keen Need breaking into three requirements?

9 4. REQUIREMENTS ANALYSIS Requirements analysis focuses on examining the gathered requirements in order to identify those that overlap, are in conflict with others or are duplicates. Requirements analysis includes: Categorisation of the requirements: general, technical, functional and non-functional (ch. 10) Applying a series of filters in order to ensure that the requirements are well defined

10 4. REQUIREMENTS ANALYSIS Requirements filters: Checking for overlapping or duplicate requirements Necessity checking Feasibility evaluation Removing conflicts Checking for solutions Confirming quality: Clear, Concise, Consistent, Unambiguous, Correct, Testable, Traceable, Accept the requirement. Re-word the requirement to remove jargon and ambiguity. Merge duplicated or overlapping requirements and reword them. Take unclear, ambiguous or conflicting requirements back to the business users for clarification.

11 5. VALIDATING REQUIREMENTS Requirements validation involves the external stakeholders reviewing the requirements in order to agree and sign off the requirements document. The reviewers should include the following representatives: The business sponsor The business owners The domain expert The developers The testers Project office external stakeholders 3 possible outcomes: Confirmed as a satisfactory statement Requires some amendments Requires significant reworking and should be reviewed again

12 GROUP PROJECT: Kelompok Week Date Case 1 dan May 2015 Internet Mini Case #1- Eli Lilly & Company 3 dan May 2015 Internet Mini Case #2 - Tech Data Corporation 5 dan May 2015 Internet Mini Case #3 - Stryker Corporation 7 dan May 2015 Internet Mini Case #4 - Sykes Enterprises 9 dan June 2015 Internet Mini Case #7 - Tyson Foods, Inc. Ketentuan: Cover: Kelompok, Nama anggota, NIM, Mata Kuliah, Kelas Isi: TNR 12, Margin 2, Spasi 1.5, Kertas A4, Staples 5-8 halaman Pertanyaan: Kondisi saat ini? Permasalahan yang dihadapi Rekomendasi (the requirements list) Note: Penggunaan problem solving model, rich picture, business model, stakeholders power map akan bermanfaat