Khawab Nama

1. INTRODUCTION TO SOFTWARE ENGINEERING

2. SOFTWARE REQUIREMENTS • Software Requirements Phase • Requirements Elicitation & its Techniques • Requirements Analysis, Specification & Notations • Requirements Validation & its Techniques

3. SOFTWARE REQUIREMENTS PHASE • A process in which “what is to be done” is gathered, modeled and communicated. Freeman • The IEEE definition (1) A condition or capability needed by a user to solve a problem or achieve an objective.

4. SOFTWARE REQUIREMENTS PHASE (2) 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 document. (3) A documented representation of a condition or capability as is 1 and 2.

10. Why Requirement Analysis &Spec.? • Domain – properties are in the application domain that are true whether or not we ever built the proposed system. • 􀂄 Library policy • 􀂄 Discount policy in a medical store etc. • Requirements – are in the application domain that we wish to be made true by delivering the proposed system. • Specification – is a description of the behaviors that the system must have in order to meet the requirements. • A process is an organized set of activities which transforms inputs to outputs.

11. Why Requirement Analysis &Spec.? System is a set of connected things that work together for a particular purpose. Subsystems • A system may have sub-systems. • A variety of possible system decompositions. Boundaries • A line between what should, and what should not be considered part of that system. Environment • Things that while not themselves part of the system can affect the operation of the system.

12. Problems with Requirements A survey of 8000 projects taken from 350 US companies described poor requirements as the major source of problems: • Lack of user involvement (13%) • Requirements incompleteness (12%) • Changing requirements (11%) • Unrealistic expectations (6%) • Unclear objectives (5%) According to Bohem “Correcting requirement errors later can cost up to 200 times as much as correcting the errors during the requirement phase”.

17. Input/output Description

18. SOFTWARE REQUIREMENTS PROCESS

19. Requirements Types • Functional requirements: Describe the interactions between the system and its environment independent from implementation • – The watch system must display the time based on its location • Nonfunctional requirements: User visible aspects of the system not directly related to functional behavior. • – The response time must be less than 1 second • – The accuracy must be within a second • Constraints (“Pseudo requirements”): Imposed by the client or the environment in which the system will operate • – The implementation language must be COBOL.

20. SOFTWARE REQUIREMENTS PHASE • Software Requirements engineering process consists of: 1. Requirement Elicitation 2. Requirement Analysis 3. Requirement Specification 4. Requirement Validation 5. Requirement Management

21. SOFTWARE REQUIREMENTS PHASE • Requirements Elicitation: – The process through which the customers, buyers, or users of a software system discover, reveal, articulate, and understand their requirements. • Requirement Analysis: – The process of reasoning about the requirements that have been elicited. – Involves examining requirements for conflicts or inconsistencies, combining related requirements, and identifying missing requirements.

22. SOFTWARE REQUIREMENTS PHASE • Requirements Specification: – The process of recording the requirements in one or more forms, including natural language and formal, symbolic, or graphical representations. • Requirement Validation: – The process of confirming with the customer or user of the software that the specified requirements are valid, correct, and complete.

23. SOFTWARE REQUIREMENTS PHASE • Requirement Management: It includes how to – Organize and store requirements – Managing changing requirements

24. REQUIREMENT ELICITATION • Identify relevant sources of requirements (the users). • Ask them appropriate questions to gain an understanding of their needs. • Analyze the gathered information, looking for inconsistencies, or unresolved issues. • Confirm your understanding of the requirements with the users. • Synthesize appropriate statements of the requirements.

25. REQUIREMENT ELICITATION Difficulties • Articulation of the users’ needs • Communication Barriers • Knowledge and Cognitive Limitations • Human Behavior Issues • Technical issues

26. REQUIREMENTS ELICITATION TECHNIQUES • Requirement Elicitation techniques include: – Interviewing – Questionnaires – JAD (Joint Application Design)

27. REQUIREMENTS ELICITATION TECHNIQUES • Interviewing • An interview with its one-on-one interaction helps IT professionals get answers to their questions. • Good preparation for interviews with introduction questions leads interviewee to focus on the topic being discussed. • Interviewer needs to prepare for the interaction, constructing at least core specifications that need to be addressed. Open-ended questions in interviews are the most effective, allowing the participant to elaborate on the point he/she is making and giving insight into his/her feeling about the problem. • However, interviewing is a lengthy process and, therefore, costly.

28. REQUIREMENTS ELICITATION TECHNIQUES • Questionnaires • Questionnaires can reach a large number of users in a short period of time. • They are easier to analyze than interviews, because they consist of multiple-choice and true and false questions created with an interpretation system in mind. • They are not as time consuming as interviews are, but a cheaper way to get feedback from users • It has a drawback that it is hard to create questionnaires that will give all possible answer options customer wants to give

29. REQUIREMENTS ELICITATION TECHNIQUES • JAD (Joint Application Design) • It is developed by IBM in late 1970's, a technique ensuring that information is gathered from all affected parties, and that requirements that are received in outcome are approved by all participants, and not only by decision of system analysts collecting the requirements. • JAD systematizes the systems requirement process, solving project managers dilemma of uniting disciplined approach to systems analysis with flexible user coordination. • JAD decreases time and costs associated with requirements elicitation process.

30. REQUIREMENTS ELICITATION TECHNIQUES • JAD sessions help bring experts together giving them a chance to share their views, understand views of others, and develop the sense of project ownership. • The techniques of JAD implementation are well known, as it is "the first accelerated design technique available on the market and probably best known“and can easily be applied by any organization.

31. REQUIREMENTS ANALYSIS • The goal of analysis is to – Discover problems – Incompleteness – Remove ambiguities – Inconsistencies in the elicited requirements – These are then feed back to the stakeholders to resolve them through the negotiation process. • Analysis is interleaved with elicitation as problems are discovered when the requirements are elicited. • A problem checklist may be used to support analysis. Each requirement may be assessed against the checklist.

32. REQUIREMENTS SPECIFICATION • Specification is the final work product produced by the requirement engineer. • It serves as the foundation for subsequent software engineering activities. • It describes the function and performance of a computer-based system and the constraints that will govern its development. • It can be a written document, a set of graphical models, a formal mathematical model, a collection of usage scenarios, a prototype, or any combination of these.

33. REQUIREMENTS NOTATIONS • Natural language + easy to read and understand - ambiguity - difficult to change • Formal languages + unambiguous + tests on consistency etc. - syntax hard to read and understand • Semi-formal language specifications, e.g. use cases

34. REQUIREMENTS VALIDATIONS • The process to prove that requirements actually define the system which the customer wants. • Requirement validation is really important because errors at this stage can cause heavily rework in future. • Developer, Customer, Users, and other stakeholders are involved in this process. • Work product conform to the standards.

35. REQUIREMENTS VALIDATIONS TECHNIQUES • Requirement reviews: – In this process a team of reviewers actually analyze the requirements systematically. • Prototyping: – An executable model of the system is demonstrated to end-users and customers. • Demonstrating that a set of requirements meets customer expectation is a difficult task to perform.

36. REQUIREMENTS VALIDATIONS CRITERIA • Correctness: The requirements represent the client’s view. • Adoptability: It can be easily changed with out affecting a large part of the system. • Clarity: There are no ambiguities in the requirements. • Traceability: There is a clear way to move from the origin to the destination of the requirement in both forward and backward direction.

43. RE Process Variability • RE processes vary radically from one organization to another. Factors contributing to this variability include: • Technical maturity • Disciplinary involvement • Organizational culture • Application domain There is therefore no ideal requirements engineering process.