1 / 47

Software Development Module Code: CST 240 Chapter 3: Requirement Analysis

Al Khawarizmi International College, Abu Dhabi, U.A.E. Software Development Module Code: CST 240 Chapter 3: Requirement Analysis. Lecturer:Karamath Ateeq. Al Khawarizmi International College, Abu Dhabi, U.A.E. Outline. Requirements Engineering Functional/non-functional requirements

eboyce
Télécharger la présentation

Software Development Module Code: CST 240 Chapter 3: Requirement Analysis

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. Al Khawarizmi International College, Abu Dhabi, U.A.E Software Development Module Code: CST 240 Chapter 3: Requirement Analysis Lecturer:Karamath Ateeq

  2. Al Khawarizmi International College, Abu Dhabi, U.A.E Outline • Requirements Engineering • Functional/non-functional requirements • Feasibility study • Requirements elicitation and analysis • Requirements validation • Requirements management Chapter 3: Requirement Analysis

  3. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements engineering • The process of eliciting, analyzing, documenting, and validating the services required of a system and the constraints under which it will operate and be developed. • Descriptions of these services and constraints are the requirements for the system. Chapter 3: Requirement Analysis

  4. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements engineering • Involves a variety of people in an organization, such as: • System end users and their managers. • Engineers who are developing or maintaining other related systems. • Trade union representatives. • Others in the organization who will be affected by the system. • All of the above are called stakeholders. Chapter 3: Requirement Analysis

  5. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements engineering Requirements engineering is a difficult process because: • Stakeholders make unrealistic demands. • Requirements are expressed in stakeholders language • Different requirements from different stakeholders • Political factors • Analysis Environment Chapter 3: Requirement Analysis

  6. Al Khawarizmi International College, Abu Dhabi, U.A.E Software System Requirement • Software System Requirements can be classified as • Functional Requirement: Functional requirement are the services the system should provide and what the software should do. • Nonfunctional Requirement: Non-functional requirements arise through user needs, because of budget constraints, because of organizational policies, because of the need for interoperability with other software or hardware systems, or because of external factors such as safety regulations or privacy legislation. Chapter 3: Requirement Analysis

  7. Al Khawarizmi International College, Abu Dhabi, U.A.E Types of Non-functional requirements • Product requirements – specify product behavior. • Organizational requirements – derived from policies / procedures in customer’s or developer’s organization (e.g., process constraints). • External requirements – derived from factors external to the product and its development process (e.g., interoperability requirements, legislative requirements). Chapter 3: Requirement Analysis

  8. Al Khawarizmi International College, Abu Dhabi, U.A.E Non-functional classifications Chapter 3: Requirement Analysis

  9. Al Khawarizmi International College, Abu Dhabi, U.A.E Examples of non-functional requirements • Product requirement: 4.C.8 It shall be possible for all necessary communication between the system and the user to be expressed in the standard Ada character set. • Organisational requirement: 9.3.2 The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95. • External requirement: 7.6.5 The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system. Chapter 3: Requirement Analysis

  10. Difference between functional and non functional requirements. Chapter 3: Requirement Analysis

  11. Chapter 3: Requirement Analysis

  12. Chapter 3: Requirement Analysis

  13. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements engineering processes • The processes used for RE vary widelydepending on the application domain, the people involved and the organization developing the requirements. • However, there are a numberofgeneric activities common to most processes: • Feasibility study • Requirements elicitation (collection) and analysis • Requirements validation Chapter 3: Requirement Analysis

  14. Al Khawarizmi International College, Abu Dhabi, U.A.E Role of the feasibility study • Identify alternatives • Analyse costs and benefits • Establish priorities • Present alternatives Chapter 3: Requirement Analysis

  15. Al Khawarizmi International College, Abu Dhabi, U.A.E Feasibility study • Determines whether or not the proposed undertaking is worthwhile. • Aims to answer three basic questions: • Would the systemcontribute to overall organizational objectives? • Could the system be engineered using current technology and within budget? • Could the system be integrated with other systems already in use? Chapter 3: Requirement Analysis

  16. Al Khawarizmi International College, Abu Dhabi, U.A.E Types of feasibility • Operational Feasibility • Identify how complex is the problem and check if the given solution will solve the problem. • It involves the analysis of: • Performance (throughput, reliability, response time, and process improvement). • Control (security and protection against fraud). • Efficiency : does the system make maximum use of available resources. • Ease of use and ease of learning. Chapter 3: Requirement Analysis

  17. Al Khawarizmi International College, Abu Dhabi, U.A.E Types of feasibility • Operational Feasibility (continued) • Will the solution fulfils the users’ requirements? To what degree? • How will the solution change the users’ work environment? • How do users feel about such a solution? Chapter 3: Requirement Analysis

  18. Al Khawarizmi International College, Abu Dhabi, U.A.E Types of feasibility • Technical Feasibility • Is the proposed technology or solution practical? • State-of-the-art (High-tech) technology vs. mature (old) technology. • Do we currently possess the necessary technology? • Do we possess the necessary technical expertise? Chapter 3: Requirement Analysis

  19. Al Khawarizmi International College, Abu Dhabi, U.A.E Types of feasibility • Schedule Feasibility • Given the current technology and technical expertise, are the project deadlines reasonable? • What happens if we don’t finish on time? Chapter 3: Requirement Analysis

  20. Al Khawarizmi International College, Abu Dhabi, U.A.E Types of feasibility • Economic Feasibility • Is the proposed system cost-effective? • What is the return-on-investment (ROI)? [ROI measures the magnitude of the benefits relative to the costs ] • What is the break-even point? [Break-even point is the time from the first money spent until the development investment has been recovered. ] Chapter 3: Requirement Analysis

  21. Al Khawarizmi International College, Abu Dhabi, U.A.E The Requirement elicitation (collection) and analysis process Chapter 3: Requirement Analysis

  22. Al Khawarizmi International College, Abu Dhabi, U.A.E The Requirement elicitation and analysis process • Domain understanding:develop an understanding of the application domain. Involves working with stakeholders to learn about the application domain, the services needed and the system’s operational constraints • Requirementscollection: the process of interacting with the stakeholders to discover requirements. • Classification: organize the unstructured collection of requirements into coherent clusters. Chapter 3: Requirement Analysis

  23. Al Khawarizmi International College, Abu Dhabi, U.A.E The Requirement elicitation and analysis process • Conflictresolution:finding and resolving conflicted requirements. • Prioritization:interacting with the stakeholders to discover the most important requirements. • Requirementsvalidation:requirements are checked to discover if they are complete, consistent, and in accordance with what the stakeholders want from the system. Chapter 3: Requirement Analysis

  24. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements Discovery Requirement discovery is the formal process of collecting information about problems, requirements, and preferences. It is also called information gathering or fact finding. The different fact finding techniques include 1- Observation: 2-     Interviewing: 3-     Questionnaires: 4-     Searching:. 5-     Sampling: Chapter 3: Requirement Analysis

  25. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements Discovery- Observation • Observation is a fact-finding technique wherein the systems analyst either participates in or watches a person perform activities to learn about the system. Chapter 3: Requirement Analysis

  26. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements Discovery - Interviews Whom to interview • Top level managers • To confirm project team understanding of the business. • To get commitment for the project. • Middle level managers • To obtain greater understanding of the problem. • To define the requirements in general terms. • Operational managers • To get a full more detailed information of the problem. • To obtain the critical points about the work procedures. Chapter 3: Requirement Analysis

  27. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements Discovery – Interview types • Unstructured interviews • Informal, the interviewer develops the theme of the interview according to the answers. • It is in the format of questions and answers. • Used when the analyst wants to get general information about the business. Chapter 3: Requirement Analysis

  28. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements Discovery – Interview types • Structured interviews • Uses standardized predefined questions in either open response or dead response format. • Uses a set of prescribed answers. • Used when the analyst wants to get full details about the business. Chapter 3: Requirement Analysis

  29. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements Discovery – Questionnaires • They are sets of predefined and standardized questions arranged on a form to obtain information about a particular subject. • They are used for: • Evaluating specific features of a system. • Investigate different opinions, knowledge, or attitudes towards the system. • They are sent via: mail, fax, e-mail, or in-person. • They should be made easy for the user to complete because: • If the user find the questions difficult, they might not complete the questionnaire, which will result in low rate of return. • Avoid ambiguity, because ambiguous questions generate unreliable answers. Chapter 3: Requirement Analysis

  30. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements Discovery – Types of Questions • Open Ended [Free Format] • Close ended [Fixed Format ] • Mixed • Open ended (or free format) :There is no predefined answers • Example: What types of computers do you currently have installed? namemodelqty Chapter 3: Requirement Analysis

  31. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements Discovery – Types of Questions • Close Ended [Fixed format ] • Example: • Multiple choice: Which of the following cities would you like to live in? • New York • London • Paris • Rome • Rating Do you feel this class is important? a) Strongly agree b) Agree c) No opinion d) disagree e) strongly disagree Chapter 3: Requirement Analysis

  32. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements Discovery – Types of Questions • Mixed • Example: In what type of business is your organization? • Government 4) Trading 2) Military 5) Others ( please specify) 3) Industrial ____________________ Chapter 3: Requirement Analysis

  33. Al Khawarizmi International College, Abu Dhabi, U.A.E Chapter 3: Requirement Analysis

  34. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements Discovery - Searching • All available written material that describes the business should be considered. In addition the documents that provide information should be catalogued for future reference. Chapter 3: Requirement Analysis

  35. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements Discovery - Searching There are 3 groups of documents: • Business documents • Annual reports, business plans and forecasting, organization chart, hand books, and advertising booklets. • Current system environment documents • System description, data administration guidelines, system architecture documents, system flowcharts, database specifications, IT organizational chart, user manual. Chapter 3: Requirement Analysis

  36. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements Discovery - Searching • Current technical environment documents • Hardware distribution list, capacity planning documents, system software list, network documents, performance statistics, hardware and software plans. Chapter 3: Requirement Analysis

  37. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements Discovery - Sampling • Sampling is the process of collecting a representative sample of documents, forms, and records. • Randomization is a sampling technique characterized as having no predetermined pattern or plan for selecting sample data. • Stratification is a systematic sampling technique that attempts to reduce the variance of the estimates by spreading out the sampling—for example, choosing documents or records by formula—and by avoiding very high or low estimates. Chapter 3: Requirement Analysis

  38. Al Khawarizmi International College, Abu Dhabi, U.A.E Viewpoint-oriented analysis • For every system there are a group of stakeholders and each group has different interest in the system, each interest is called aviewpoint. • To illustrate viewpoints lets take the example of ATM stakeholders Chapter 3: Requirement Analysis

  39. Al Khawarizmi International College, Abu Dhabi, U.A.E ATM stakeholders • Bank customers • Representatives of other banks • Bank managers • Counter staff • Database administrators • Security managers • Marketing department • Hardware and software maintenance engineers • Banking regulators Chapter 3: Requirement Analysis

  40. Al Khawarizmi International College, Abu Dhabi, U.A.E Viewpoint-oriented analysis Any viewpoint may be considered as: • A data source or sink • In this case the analyst must identify what data is produced or consumed and what is the process of doing that. • A cross-check is made to discover data being produced but not consumed or vice versa. • Used by the CORE method. Chapter 3: Requirement Analysis

  41. Al Khawarizmi International College, Abu Dhabi, U.A.E Viewpoint-oriented analysis • A representation framework • In this case, each viewpoint is represented by a different data model. • The data models are cross-checked to discover requirements that would be missed. • Used by the VOSE method Chapter 3: Requirement Analysis

  42. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirement Validation • Requirements validation is an activity that checks the requirements definition document for accuracy, completeness, consistency, and conformance to standards. • Concerned with whether or not the requirements define a system that the customer really wants. • Requirements error costs are high, so validation is very important. Chapter 3: Requirement Analysis

  43. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements checking • Validity. Does the system provide the functions which best support the customer’s needs? • Consistency. Are there any requirements conflicts? • Completeness. Are all functions required by the customer included? • Realism. Can the requirements be implemented given available budget and technology • Verifiability. Can the system be tested to determine whether or not the requirements are met? Chapter 3: Requirement Analysis

  44. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements validation techniques • Requirements reviews / inspections – systematic manual analysis of the requirements. • Prototyping – using an executable model of the system to check requirements. • Test-case generation – developing tests for requirements to check testability. • Automated consistency analysis – checking the consistency of a structured requirements description. Chapter 3: Requirement Analysis

  45. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements management • Requirements management is the process of managing changing requirements during the requirements engineering process and system development. • New requirements emerge during the process as business needs change and a better understanding of the system is developed. Chapter 3: Requirement Analysis

  46. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements management • The priority of requirements from different viewpoints changes during the development process. • The business and technical environment of the system changes during its development. Chapter 3: Requirement Analysis

  47. Al Khawarizmi International College, Abu Dhabi, U.A.E Requirements change management Chapter 3: Requirement Analysis

More Related