CSE 360 Week 5 (pt3)
CSE 360 Week 5 (pt3) CSE 360
Popular in Software Engineering
Popular in Computer Science and Engineering
This 5 page Class Notes was uploaded by Alexandra Notetaker on Thursday September 15, 2016. The Class Notes belongs to CSE 360 at Arizona State University taught by Debra Calliss in Fall 2016. Since its upload, it has received 2 views. For similar materials see Software Engineering in Computer Science and Engineering at Arizona State University.
Reviews for CSE 360 Week 5 (pt3)
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 09/15/16
CSE 360 REQUIREMENTS ENGINEERING Requirements Engineering Process of establishing the services that a customer requires from a system and the constraints under which it operates and is developed System requirements: descriptions of the system services and constraints that are generated during the requirements engineering process Types of requirements User Requirements: Statements in natural language plus diagrams of the services the system provides and its operational constraints System Requirements: A structured document setting out detailed descriptions of the system’s functions, services, and operational constraints. Defines what should be implemented; so may be a part of a contract between client and contractor. Functional Requirements Describe functionality or system services Depend on the type of software, expected users and the type of system where the software is used. Functional user requirements: May be high-level statements of what the system should do. Functional System Requirements: Should describe the system services in detail Requirements: Completeness & consistency Complete: Include descriptions of all facilities requires Consistent: No conflicts in descriptions of system facilities BUT In practice, b/c system and environmental complexity it is impossible to produce complete and consistent required documents. Non-Functional Requirements Define system priorities and constraints (i.e. reliability, response time, ad storage requirements) Process requirements may also mandate particular IDE, language, or development method. May be more critical than functional—if not met, system = useless Types of Non-Functional Requirements How can you measure Non-Functional Requirements Requirements Engineering Process Widely dependent of application domain, people involved, and organization developing requirements: Common processes: Requirements elicitation Requirements analysis Requirements validation Requirements management In practice, (RE) is an iterative activity and processes are interleaved Requirements Elicitation Find application domain, services, performance, hardware, constraints, other systems, etc. Stages: Requirements discovery Requirements classification and organization Requirements Prioritization and Negotiation Requirements Specification Problems of Requirements Elicitation Stakeholders don’t know what they want Stakeholders express requirements in their own terms Different stakeholders may have conflicting requirements Organizational and political factors may influence requirements New stakeholders may emerge and business environments change Interviewing Formal/informal interviews with stakeholders (RE) process Types of interview: Closed: pre-determined questions Open: various issues explored Effective interviewing Open-minded: avoid pro-conceived ideas and listen Prompt discussion: Springboard question Requirements proposal Prototype system Stories and scenarios = use cases Real-life example of how they system can be used. Stories/scenarios = description of how system may be used for a particular task b/c they are based on practical solutions, stakeholders can relate to them, and can comment with respect to the story System Requirements Specification Representations Guidelines for writing requirements Use standard format for all requirements Use language consistently Shall = mandatory Should = desirable Use text highlighting key parts Avoid computer jargon Include explanation Problems with Natural Language Lack of clarity Precision s difficult without making the document difficult to read Requirements confusion Functional/Non-Functional requirements get mixed up Requirements Amalgamation Several requirements expressed together Software Requirements Document Official statement of requirements for software developers Include definition of user requirements and specification of the system requirements NOT a design document Sets what they system should do and how it should do it. User Requirements Document Requirements Validation Demonstrating that the requirements define customer needs Requirements error costs = high Validation is very important Fixing requirement errors cost 100x the cost of fixing implementation error Requirements Checks Validity Consistency Completeness Realism Verifiability Requirements Validation Techniques Requirements Reviews: Systematic manual analysis of requirements Prototyping: Using executable model of system to check requirements Test case generation: Developing tests for requirements to check testability Requirements Reviews Regular reviews help while requirements are formulated Client and contractor staff involved Formal/informal: good communication to resolve problems early Review Check Verifiability Requirements realistically testable Comprehensibility Requirements understood Traceability Origin of requirement stated Adaptability Requirement can be changes without a large impact
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'