1 / 155

CSDP Preparation Course Module II: Software Requirements

CSDP Preparation Course Module II: Software Requirements. Specifications. The exam specific topics covered in this module are listed below, and are the basis for the outline of its’ content. Requirements Engineering Process Requirements Elicitation Requirements Analysis

wilfong
Télécharger la présentation

CSDP Preparation Course Module II: Software 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. CSDP Preparation CourseModule II: Software Requirements

  2. Specifications The exam specific topics covered in this module are listed below, and are the basis for the outline of its’ content. • Requirements Engineering Process • Requirements Elicitation • Requirements Analysis • Software Requirements Specification • Requirements Validation • Requirements Management Module II. Software Requirements

  3. After completing this module, you should be able to… To present an overview of software requirements engineering Objectives Module II. Software Requirements

  4. Organization The organization of information for each specification topic is as follows: • Topic Content Slides - detail the important issues concerning each topic and support the module objectives • Topic Reference Slides - detail the sources for the topical content and provides additional references for review • Topic Quiz Slides - allow students to prepare for the exam Module II. Software Requirements

  5. Introduction What is Software? • software -- Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system. Contrast with hardware. [IE610] What is a Requirement? • requirement -- (1) A condition or capability needed by a user to solve a problem or achieve an objective. (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 documents. (3) A documented representation of a condition or capability as in (1) or (2). [IE610] Module II. Software Requirements

  6. Introduction – 2 A Perspective • These definitions imply concern for the user of the software as well as the developer. • Wiegers emphasizes that the term users in such a definition should be generalized to stakeholders, because not all stakeholders are users. • CAUTION: Don’t assume that all your project stakeholders share a common notion of what requirements are. Establish definitions up front so that you’re all talking about the same things. [KW03, p. 8] Module II. Software Requirements

  7. Introduction – 3 Major Issues in Software Requirements • The incorrect and incomplete software requirements specification • The truncation of requirements activities over programming and testing • The lack of cooperation by customers: • To verify that the software requirements are correct • To understood the structure and purpose of the software requirements specifications • The problems associated with identifying which tool and/or methodology to use in developing and representing a software requirements specification [RT04, p. 4-9] Module II. Software Requirements

  8. Introduction – 4 Fundamentals of Requirements • In order to properly identify a requirement, we may apply the general property distinctions that the SWEEBOK Guide has identified [SW04, p. D-3]: • Product and process requirements • Functional and non-functional requirements • Emergent properties • Quantifiable requirements • System requirements and software requirements Module II. Software Requirements

  9. Introduction – 5 Product and Process Requirements - I • Product parameter – a requirement on software to be developed • Product requirement – Requirements which apply to the product of services to be developed • Qualitative parameters – not directly measurable • Functional – What it does • External Interfaces – Data or command inputs or outputs • Quantitative parameters – directly measurable • Performance metrics – How fast, how much memory • Quality metrics – Reliability, maintainability, security [RT04, p. 4-13] Module II. Software Requirements

  10. Introduction – 6 Product and Process Requirements - II • Process parameter – essentially a constraint on the development of the software (AKA process requirements) • Process (Program) requirements – Applies to the activities associated with enabling the creation of a product or service • Task – Perform and analyze, develop a product, operate a system • Compliance evaluation – Measure compliance with a product parameter • Regulatory/Standards – Compliance with laws, standards, regulations, and rules Module II. Software Requirements

  11. Introduction - 7 Functional and Non-functional Requirements • Functional requirements – describes functions software is to execute • Example: formatting text • Non-functional requirements – ones that act to constrain the software solution • Further classes – performance, maintainability, safety, reliability, and others. Module II. Software Requirements

  12. Introduction - 8 Emergent Properties • Emergent properties – those which cannot be addressed by a single component, but system component interoperability • Highly sensitive to the system architecture • Sommerville provides three examples [IS01, p. 22]: • Overall weight of the system • Reliability of the system • Usability of the system Module II. Software Requirements

  13. Introduction – 9 Quantifiable Requirements • Avoid vague and unverifiable requirements which depend for their interpretation on subjective judgment • This is critical for non-functional requirements Module II. Software Requirements

  14. Introduction – 10 System Requirements and Software Requirements • System requirements - are for the system as a whole; sometimes referred to as user requirements • Includes hardware, software, firmware, people, information, techniques, facilities, services, and other support elements • Software requirements – derived from system requirements Module II. Software Requirements

  15. Introduction – 11 Recognizing the Importance of Software Requirements Engineering [RT04, p. 4-7] • Better quality in the software development process and the software product can be obtained if our methods and tools for gathering, modeling and analyzing user requirements are more effective, robust and codified in practice, i.e. an engineering approach • Therefore, software requirements engineering (SRE) has emerged as an “engineering” approach to what used to be called requirements analysis and specifications Module II. Software Requirements

  16. Introduction – 12 Role of Software Requirements in the Lifecycle [RT04, p. 4-17] • Describes what the user wants or needs done • Describes the final product, not methods and techniques for building the software • Provides the basis for cost, schedule, and other resource estimates • Primarily developed during the requirements phase of the lifecycle • Can be developed in other phases of the lifecycle Module II. Software Requirements

  17. Introduction Quiz 1. Which of the following requirement properties would be considered an emergent property of a software program? • The fault detection system of the software • The programming language of the system • The reliability of the software • The number of lines of code Module II. Software Requirements

  18. Introduction Quiz – 2 2. Which of the following would most likely be considered a product requirement? • The software shall be written in Ada. • The student name shall be entered before the student grade. • The system requirements for the software shall be formatted according to IEEE Std 1233. • The software is built with company standards. Module II. Software Requirements

  19. Introduction Quiz – 3 3. Which of the following is most true about a non-functional requirement? • Describes functions software is to execute. • Is highly sensitive to the system architecture. • Is derived from hardware requirements. • Acts to constrain the software solution. Module II. Software Requirements

  20. Introduction References • [IE610] IEEE Std 610.12-1990, Standard Glossary of Software Engineering Terminology • [IE1233] IEEE Std 1233-1998, Guide for Developing System Requirements • [IS01] Sommerville, Ian, Software Engineering, 6th Edition, Addison-Wesley, NY, 2001 • [KW03] Weigers, Karl E., Software Requirements, 2nd Edition, Microsoft Press, Redmond, WA, 2003 • [RT04] Thayer, Richard, 2004 Certified Software Development Professional (CSDP) Preparation Course, Chapter 4: Software Requirements Engineering Concepts • [SW04] SWEBOK – Guide to the Software Engineering Body of Knowledge: 2004 Version, IEEE Computer Society, Los Alamitos, CA, Chapter 2 – Software Requirements Module II. Software Requirements

  21. A. Requirements Engineering Process A Process Defined • process -- (1) A sequence of steps performed for a given purpose; for example, the software development process. (2) An executable unit managed by an operating system scheduler. (3) To perform operations on data. [IE610] • Software requirements engineering (SRE) is a process, not a discrete activity Module II. Software Requirements

  22. A. Requirements Engineering Process - 2 Software Requirements Engineering Process - I • Collect and categorize the various requirements (requirements elicitation) • Identify relevant sources of requirements (usually the customers) • Determine what information is needed (this will change as the requirements are developed) • Collect the requirements from all parties Module II. Software Requirements

  23. A. Requirements Engineering Process - 3 Software Requirements Engineering Process - II • Analyze the gathered information, looking for implications, inconsistencies, or unresolved issues (analysis) • Synthesize appropriate statements of the requirements (specifications) • Confirm your understanding of the requirements with the users (verification) • Plan and control the effort from beginning to end (management) [RT04, p. 4-20] Module II. Software Requirements

  24. A. Requirements Engineering Process - 4 SRE Process Activities - I • Software requirements elicitation – The process through which the customers (buyers and/or users) and developers (contractors) of a software system discover, review, articulate, and understand their requirements • Software requirements analysis – Reasoning and analyzing the customers’ and users’ needs to arrive at a definition of software requirements Module II. Software Requirements

  25. A. Requirements Engineering Process - 5 SRE Process Activities - II • Software requirements specification – A document that clearly and precisely records each of the requirements of the software system • Software requirements verification – The assurance that software requirements specifications are in compliance with the system requirements, conforms to document standards of the requirements phase, and is an adequate basis for the architectural (preliminary) design phase • Software requirements management - Planning and controlling the requirements elicitation, analysis, and verification activities [RT04, p. 4-19] Module II. Software Requirements

  26. A. Requirements Engineering Process - 6 Process Models • Provide a basic outline of the requirements process • Obtaining software requirements is not a discrete front-end activity • Initiated at the beginning of the project, and is refined throughout the life cycle • Software requirements are configuration items for management • The process is adapted to the organization and the project • Four major activities: elicitation, analysis, specification, and validation Module II. Software Requirements

  27. A. Requirements Engineering Process - 7 Process Actors - I • Those who participate in the process • The requirements specialist mediates between domain of the stakeholder and software engineer • Always include users (or operators) and customers (they may not be the same) Module II. Software Requirements

  28. A. Requirements Engineering Process - 8 Process Actors - II • Typical software stakeholders • Users – Will operate software • Customers – Commissioned the software • Market analyst – Act as proxy customers • Regulators – Authorities from application domains (EX: banking,) • Software engineers – Have a stake in reusing components in successful products; must weigh their personal against the stake of the customer • Must negotiate trade-offs with stakeholders to their satisfaction, within project constraints • Stakeholders must be identified before this negotiation to occur [SW04, p. 2-3] Module II. Software Requirements

  29. A. Requirements Engineering Process - 9 The Importance of Software Requirements These PeopleDepend on SW Req. to: Acquisition management Establish their needs Project management Determine tasks and schedule System engineers Req. allocated to SW Testers Establish what is to be tested SW engineers Establish top-level design Configuration control Establish req. baseline Everyone Guide their effort - [RT04, p. 4-22] Module II. Software Requirements

  30. A. Requirements Engineering Process - 10 Process Support and Management • Linked to the four major process activities: elicitation, analysis, specification, and validation • Concerned with issue of cost, human resources, training, and tools Module II. Software Requirements

  31. A. Requirements Engineering Process - 11 Process Quality and Improvement • Concerned with assessment of the process • Measured by cost, schedule, and customer satisfaction • Uses: • Process improvement standards and models • Requirements process measures and benchmarking • Improvement planning and implementation Module II. Software Requirements

  32. A. Requirements Engineering Process - 12 Other Issues in Software Requirements Engineering – I • Requirements specifications often do not reflect the need and desires of the users and the customer • Software requirements specifications are often incomplete and incorrect • Users’ knowledge, experience, and cooperation greatly influence the quality of the specifications • Developer’s knowledge of the customer domain greatly influence the quality of the specifications Module II. Software Requirements

  33. Requirements Engineering Process – 13 Other Issues in Software Requirements Engineering – II • Software requirements are constantly undergoing change • Requirements sometimes specify the software design (a design constraint) • Design is changed without a corresponding change in requirements [RT04, p. 4-22] Module II. Software Requirements

  34. A. References • [IE610] IEEE Std 610.12-1990, Standard Glossary of Software Engineering Terminology • [RT04] Thayer, Richard, 2004 Certified Software Development Professional (CSDP) Preparation Course, Chapter 4: Software Requirements Engineering Concepts • [SW04] SWEBOK – Guide to the Software Engineering Body of Knowledge: 2004 Version, IEEE Computer Society, Los Alamitos, CA, Chapter 2 – Software Requirements Module II. Software Requirements

  35. A. Quiz 1. According to the SWEBOK Guide, what are the four major activities of the requirements engineering process? • Identification, specification, construction, and testing • Elicitation, analysis, specification, and validation • Analysis, planning, construction, and verification • Elicitation, planning, construction, and testing Module II. Software Requirements

  36. A. Quiz – 2 2. Which of the following property is least critical to the interaction between process actors and the requirements process? • Process actor identification • The nature of their ‘stake’ in the process • The education of the actor • The requirements they elicit Module II. Software Requirements

  37. A. Quiz – 3 3. The requirements engineering process is: • A discrete front-end activity of the software life cycle. • Initiated at the beginning of a project and continues to be refined throughout the lifecycle. • A continuous process that ends when requirements are specified and documented. • The same for each organization and process. Module II. Software Requirements

  38. A. Quiz – 4 4. Process quality and improvement relies most on which of the following? • Product operator performance • Human factors • Requirements process measures • Customer preferences Module II. Software Requirements

  39. A. Quiz – 5 5. Product requirement validation occurs primarily after: • Elicitation • Analysis • Specification • Testing Module II. Software Requirements

  40. B. Requirements Elicitation What is Requirements Elicitation? • Concerned with where software requirements come from and how the software engineers can collect them. • Stakeholders are identified and relationships established between the development team and the customer • Also known as ‘requirements capture’, ‘requirements discovery’, and ‘requirements acquisition’ [SW04, p. 2-4] Module II. Software Requirements

  41. B. Requirements Elicitation - 2 Major Issues Involving Requirements Elicitation - I • It is not always clear who your customers or users are. • Your customers/users cannot always state their requirements clearly or completely. • Users don’t know what they want; they only know what they do. • What they say they want may not be what they need or you may begin to define what you think they need, instead of what they want. Module II. Software Requirements

  42. B. Requirements Elicitation - 3 Major Issues Involving Requirements Elicitation - II • Their concept of the solution may not solve their problem. • The customers or users will have expectations that may be unreasonable – or unknown to you. • Not all of your customers or users talk to or agree with one another, so you must talk to all of them. • Your customers or users may change. [RT04, p. 4-25] Module II. Software Requirements

  43. B. Requirements Elicitation - 4 Requirements Sources - I • From the SWEBOK Guide [SW04, p. 2-4] • Goals – • Sometimes called ‘business concern’ or ‘critical success factor’ • Provides motivation for the software, but are often vaguely formulated • Focus is to assess the value (relative priority) and cost of goals • A feasibility study can do this at low cost • Domain knowledge - • The software engineer needs to be knowledgeable of the application domain • Allows for assessment of that which is not articulated Module II. Software Requirements

  44. B. Requirements Elicitation - 5 Requirements Sources - II • Stakeholders – • Also known as Process Actors • The software engineer needs to identify, represent, and manage the ‘viewpoints’ of many different types of stakeholders • The operational environment – • The environment that software will be executed in will reveal system constraints and system element interoperability • The organizational environment – • May impose previously unidentified user processes Module II. Software Requirements

  45. B. Requirements Elicitation - 6 Elicitation Techniques - I • From SWEBOK Guide [SW04, p. 2-4] • Once requirements sources have been identified, the software engineer can start eliciting requirements from them. • Even if sources are cooperative and articulate, the relevant information must be captured. Some of these techniques are: • Interviews – • A traditional means of eliciting requirements Module II. Software Requirements

  46. B. Requirements Elicitation - 7 Elicitation Techniques - II • Scenarios – • Provides a context for elicitation of user requirements • Asks ‘what if’ and ‘how is this done’ questions • The most common type of scenario is the use case • Link to Conceptual Modeling because of scenario notations such as use cases and diagrams are common in modeling software • Prototypes – • Form paper mock-ups of screen designs to beta-test versions of software products • Valuable tool for clarifying unclear requirements • Overlap for use in requirements elicitation and requirements validation Module II. Software Requirements

  47. B. Requirements Elicitation – 8 Elicitation Techniques - III • Facilitated meetings – • A group of people may bring more insight to achieve a summative effect to the requirements • Conflicting requirements may surface earlier in this setting • Beware of stakeholder politics • Observation – • Software engineers are immersed in the environment to observe the user interact between the software and other users • Expensive to implement • Helps reveal process subtleties and complexities Module II. Software Requirements

  48. B. Requirements Elicitation – 9 ConOps - An Elicitation Tool - I • Definition – concept of operations (ConOps) document – A user oriented document that describes a system’s operational characteristics from the end user’s viewpoint. [IE1362, Definition 3.4] • It describes the user organization(s), mission(s), and organizational objectives from an integrated systems point of view. • Applied to all types of software intensive systems: software-only or software/hardware/people systems Module II. Software Requirements

  49. B. Requirements Elicitation – 10 ConOps - An Elicitation Tool - II • Describes the user’s general system goals, missions, function, and components • Helps bring the users’ views and expectations to the surface • Provides an outlet for the users’ wishes and wants • Helps the user feel in control • May or may not be the responsibility of the acquisition manager [RT04, p. 4-29] Module II. Software Requirements

  50. B. Requirements Elicitation – 11 The ConOps Document Style • A ConOps document must be written in the user’s language using the user’s format • A ConOps document should be written in narrative prose (in contrast to a technical requirements specification) • ConOps should make use of visual forms (diagrams, illustrations, graphs, etc.) and storyboards wherever possible • ConOps provides a bridge between the user needs and the developer’s technical requirements documents [RT04, p. 4-28] Module II. Software Requirements

More Related