SEG3201 Basics of the Requirements Process
|
|
- Beverley George
- 6 years ago
- Views:
Transcription
1 SEG3201 Basics of the Requirements Process Based on material from: I Bray: An introduction to Requirements Engineering Gerald Kotonya and Ian Sommerville: Requirements Engineering Processes and Techniques, Roger S Pressman: Software Engineering A practitioner's Approach 1
2 Objectives Definition of requirements and requirements types Introduction to requirements process Requirements activities Importance of a requirements process 2
3 What are requirements? According to the IEEE A requirement is defined as: (1) a condition or capability needed by a user to solve a problem or achieve an objective; (2) a condition or a capability that must be met or possessed by a system to satisfy a contract, standard, specification, or other formally imposed document 8
4 What are requirements? Requirements capture a system purpose Requirements are expression of the ideas to be embodied in the system or application under development A requirements is a statement about the proposed system that all stakeholders agree must be made true in order for the customer s problem to be adequately solved. Short and concise piece of information Says something about the system All the stakeholders have agreed that it is valid It helps solve the customer s problem 9
5 Requirements Process All the activities that go into the instigation, scoping and definition of a new or altered software system. Identification of the purpose of a software system and the contexts in which it will be used. Captures real world needs of stakeholders affected by a software system and express them as artifacts that can be implemented by a computing system. Also referred as Requirements Engineering 10
6 Set of activities Requirements Process not a phase Applies to new as well as evolutive systems Takes context into account how/where system will be used BIG picture important Deals with stakeholders who are they? communication Translates between different worlds Is anything lost in the translation? bridge to design and construction 11
7 Why is the requirements process important? NIST (National Institute of Standards and Technology's) has published a comprehensive (309 pages) and very interesting report on project statistics and experiences based on data from a large number of software projects 10.htm (May 2002). 70 % of the defects are introduced in the specification phase 30 % are introduced later in the technical solution process. Only 5 % of the specification inadequacies are corrected in the specification phase 95 % are detected later in the project or after delivery where the cost for correction in average is 22 times higher compared to a correction directly in the specification effort. The NIST report concludes that extensive testing is essential, however testing detects the dominating specification errors late in the process. 18
8 Why is the requirements process important? SEI has an alternative view on improving software development with the CMM/CMMI model for software development. The SEI vision is : The right software, delivered defect free, on time and on cost, every time. "Right software" implies software that satisfies requirements for functionality, performance, and cost throughout its lifetime. "Defect free" software is achieved either through exhaustive testing after coding or by developing the code right the first time. 19
9 General Problems with the Requirements Process Lack of right expertise (software engineers, domain experts, etc) Initial ideas are often incomplete, wildly optimistic, and firmly entrenched in the minds of the people leading the acquisition process Difficulty of using the complex tools and diverse methods associated with requirements gathering may negate the hoped for benefits of a complete and detailed approach. 20
10 Types of Requirements Traditional categorization of requirements Functional requirements: functions and features Non functional requirements: constraints on any solution Other terminology Goals: objectives or concerns used to discover and evaluate functional and non functional requirements Domain requirements: requirements derived from application domain User requirements: desired goal or function that a user and other stakeholders expect the system to achieve 21
11 System requirements vs Software requirements Software is sometimes part of a system A collection of inter related components working together towards some common objective Components may include software, mechanical, electrical and electronic hardware and be operated by people System Engineering Multi disciplinary approach to systems development Software only a part (but often the problematic part) 22
12 System requirements vs Software requirements According to the IEEE System requirements are the requirements for the system as a whole. In a system containing software components, Software requirements are derived from system requirements. 23
13 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 but functional system requirements should describe the system services in detail 24
14 Functional requirements What inputs the system should accept? What outputs the system should produce? What data the system should store that other systems might use? What computations the system should perform? The timing and synchronization of the above? 25
15 Examples of functional requirements The user shall be able to search either all of the initial set of databases or select a subset from it. The system shall provide appropriate viewers for the user to read documents in the document store. Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account s permanent storage area. 26
16 Non functional requirements Define system properties and constraints Non functional requirements may be more critical than functional requirements. If these are not met, the system is useless 27
17 Goals Non functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify. Goal A general intention of the user such as ease of use Convey the intention of the system users Verifiable non functional requirement A statement using some measure that can be objectively tested Requirements should be verifiable 28
18 Examples of Goals A system goal The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized. A verifiable non functional requirement Experienced controllers shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day. 29
19 Non Functional Requirements Three main types 1. Categories reflecting: usability, efficiency, reliability, maintainability and reusability Response time Throughput Resource usage Reliability Availability Recovery from failure Allowances for maintainability and enhancement Allowances for reusability 30
20 Non Functional Requirements 2. Categories constraining the environment and technology of the system. Platform (minimal requirements, OS, devices ) Technology to be used (language, DB, ) 3. Categories constraining the project plan and development methods Development process (methodology) to be used Cost and delivery date Often put in contract or project plan instead 31
21 Non functional requirements types (Sommerville & Kontoya 1998) Non functional requir ements Product requir ements Ef ficiency requir ements Reliability requir ements Usability requirements Performance requirements Or ganizational requir ements Portability requirements Delivery requirements Space requir ements External requirements Interoperability requirements Implementation requir ements Ethical requirements Standards requirements Legislative requirements Privacy requirements Safety requirements 32
22 Examples of non functional requirements Product requirement Organisational requirement It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character set The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo SP STAN 95 External requirement The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system 33
23 Requirements measure (Sommerville & Kontoya 1998) Pro perty Speed Size Ease of use Rel iabil it y Robust ness Port abil it y Measure Processed t ransact ions/second U ser/event response t ime Screen refresh t ime K Byt es N umber of RAM chips Training t ime N umber of hel p frames M ean t ime t o fail ure Probabil it y of unavail abil it y Rat e of fail ure occurrence A vail abil it y Time t o rest art aft er fail ure Percent age of event s causing fail ure Probabil it y of dat a corrupt ion on fail ure Percent age of t arget dependent st at ement s N umber of t arget syst ems 34
24 Domain Requirements Derived from the application domain and describe system characteristics and features that reflect the domain May be new functional requirements, constraints on existing requirements or define specific computations If domain requirements are not satisfied, the system may be unworkable 35
25 Examples of domain requirements Library system There shall be a standard user interface to all databases which shall be based on the Z39.50 standard. Because of copyright restrictions, some documents must be deleted immediately on arrival. Depending on the user s requirements, these documents will either be printed locally on the system server for manually forwarding to the user or routed to a network printer. 36
26 Requirements Process and related Activities Requirements Process Requirements Inception Elicitation Requirements Development Analysis Requirements Management Specification Verification Based on Larry Boldt, Trends in Requirements Engineering People Process Technology, Technology Builders, Inc.,
27 Requirements Process and Related Activities Inception Starts process (business need, market opportunity, great idea,...). Business case and feasibility are built. Requirements elicitation Requirements discovered through consultation with stakeholders Requirements analysis and negotiation Requirements are analyzed and conflicts resolved through negotiation Requirements specification A precise requirements document is produced Requirements validation The requirements document is checked for consistency and completeness Requirements management To cope with requirements changes. Continuous interaction with customers, traceability,... 42
28 Problem Domain Context for requirements part of the world within which the problem exists need to be understood for effective requirements engineering Domain model set of properties assumed / believed to be true about the environment, relevant to the problem system supposed to behave as required if assumptions are verified problem domain interface solution system A domain model should be re-usable (from Jackson 1995) 49
29 Requirements Inception Start the process Identification of business need New market opportunity Necessity Great idea Involves Building a business case Preliminary feasibility assessment Preliminary definition of project scope Stakeholders: business managers, marketing people, product managers,... Example of technique: Brainstorming, Joint Application Development (JAD) meeting 50
30 Requirements Elicitation Gathering of information About problem domain About problems requiring solution About constraints on problem or solution Questions that need to be answered What is the system? What are the goals of system? How is the work done now? What are the problems? How will the system solve these problems? How will the system be used on day to day basis Will performance issues or other constraints affect the way the solution is approached? 51
31 Requirements Analysis The process of studying and analyzing the customer and the user needs to arrive at a definition of software requirements. Objectives detect and resolve conflicts between requirements discover the bounds of the software and how it must interact with its environment elaborate system requirements to derive software requirements 52
32 Requirements Specification The invention and definition of a behaviour of a new, solution system such that it will produce the required effects in the problem domain Requirements Analysis defined problem domain and required effects Specification Document A document that clearly and precisely describes, each of the essential requirements (functions, performance, design constraint, and quality attributes) of the software and the external interfaces. Each requirement being defined in such a way that its achievement is capable of being objectively verified by a prescribed method; for example inspection, demonstration, analysis, or test Different guidelines specification and templates for requirements 53
33 Requirements Verification and Validation Checks that product is being built right Checks that the right product is being built Helps ensure delivery of what the client wants highly pertinent to RE Need to be performed at every stage during the process Different techniques Simple checks Review Logical analysis Prototypes and enactments Functional test design User manual development 54
34 Requirements Management Necessary to cope with requirements change Requirements change because: Business process changes Technology changes The problem becomes better understood Traceability is very important R e q u ir e m e n t s docu m en t ra tio n a le 1.1 X X X X... b e c a u s e 1.2 Y Y Y Y D e s ig n docu m en t...d u e t o r e q u i r e m e n t 1.2 Changing requirements is as certain as death and taxes 55
35 Requirements Products Elicitation notes (Raw) requirements obtained through elicitation. Often un structured, incomplete and inconsistent. Requirements documents User (customer) requirements Detailed requirements (system requirements) Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor Software specification A detailed software description which can serve as a basis for a design or implementation. Written for developers 57
36 Requirements Products (Sommerville & Kontoya 1998) Requirements definition 1. The software must provide a means of repr esenting and 1. accessing external files created by other tools. Requirements specification 1.1 The user should be provided with facilities to define the type of 1.2 external files. 1.2 Each external file type may have an associated tool which may be 1.2 applied to the file. 1.3 Each external file type may be represented as a specific icon on 1.2 the user s display. 1.4 Facilities should be provided for the icon repr esenting an 1.2 external file type to be defined by the user. 1.5 When a user selects an icon repr esenting an external file, the 1.2 effect of that selection is to apply the tool associated with the type of 1.2 the external file to the file represented by the selected icon. 58
37 Types of Requirements Documents Two extremes: An informal outline of the requirements using a few paragraphs or simple diagrams requirements definition A long list of specifications that contain thousands of pages of intricate detail requirements specification Requirements xxx x xx xxx x subsystem 1 Requirements documents for large systems are normally arranged in a hierarchy Requirements xxx x xx xxx x sub subsystems Requirements Requirements Requirements Requirements Definition Definition Definition Definition xxx Requirements xxx Requirements xxx Requirements xxx Requirements x Specification Specification x Specification x xx x Specification xx xx xx xxx xxx xxx xxx xxx xxx x xxx xxx x x x x x x xx x xx xx xx xxx xxx xxx x xxx xx x subsystem 2 Requirements Definition Requirements xxx Specification x xx xxx xxx x x xx xxx x sub subsystems Requirements Requirements Requirements Requirements Definition Definition Definition Definition xxx Requirements xxx Requirements Requirements xxx xxx Requirements x Specification Specification Specification x x xx x Specification xx xx xx xxx xxx xxx xxx xxx xxx x xxx xxx x x x x x x xx x xx xx xx xxx xxx xxx x xxx xx x 59 59
38 The Requirements Analyst Plays an essential communication role talks to users: application domain talks to developers: technical domain translates user requirements into functional requirements and quality goals Needs many capabilities interviewing and listening skills facilitation and interpersonal skills writing and modeling skills organizational ability RE is more than just modeling This is a social activity! 60
Basics : the Requirements Engineering Process
SEG3101 (Fall 2010) Basics : the Requirements Engineering Process Gregor v. Bochmann, University of Ottawa Based on Powerpoint slides prepared by Gunter Mussbacher with material from: Sommerville & Kotonya
More informationRequirements Engineering. Establishing what the customer requires from a software system. Requirements Engineering. What is a Requirement?
Engineering Establishing what the customer requires from a software system Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 5 and 6 Slide 1 Engineering
More informationSE351a: Software Project & Process Management. 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa
SE351a: Software Project & Process Management W4.1: Requirements Engineering 11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa SE351 Roadmap Introduction to Software Project Management Project Management
More informationSoftware Engineering. Lecture 10
Software Engineering Lecture 10 1. What is software? Computer programs and associated documentation. Software products may be: -Generic - developed to be sold to a range of different customers - Bespoke
More informationIan Sommerville 2006 Software Engineering, 8th edition. Chapter 6 Slide 1
Software Requirements Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 6 Slide 1 Objectives To introduce the concepts of user and system requirements To describe functional and non-functional
More informationRequirements. Requirements. Types of Requirement. What Is a Requirement?
Beatrice Åkerblom beatrice@dsv.su.se Everything else in software development depends on the requirements. If you cannot get stable requirements you cannot get a predictable plan... What Is a Requirement?!
More informationRequirement Analysis
Requirement Analysis Requirements Analysis & Specification Objective: determine what the system must do to solve the problem (without describing how) Done by Analyst (also called Requirements Analyst)
More informationRequirements Engineering. Version October 2016
Requirements Engineering Version 1.11 26 October 2016 Maurizio Morisio, Marco Torchiano, 2016 Software development Customer Needs Acceptance testing Requirements Analysis System testing System Design Integration
More informationSoftware Requirements and the Requirements Engineering Process. Chapters 5 and 6
Software Requirements and the Requirements Engineering Process Chapters 5 and 6 References Software Engineering. Ian Sommerville. 6th edition. Pearson. Code Complete. Steve McConnell. (CC) The art of triage.
More informationRequirements Engineering: Specification & Validation. Software Requirements and Design CITS 4401 Lecture 18
Requirements Engineering: Specification & Validation Software Requirements and Design CITS 4401 Lecture 18 The Problems of Requirements What goal(s) are we trying to satisfy? How do we identify the scope
More informationLecture 6: Requirements Engineering
Lecture 6: Requirements Engineering Software System Design and Implementation ITCS/ITIS 6112/8112 001 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte
More informationCIS 890: Safety Critical Systems
CIS 890: Safety Critical Systems Lecture: Requirements Introduction Copyright 2011, John Hatcliff. The syllabus and all lectures for this course are copyrighted materials and may not be used in other course
More informationThe Analysis and Proposed Modifications to ISO/IEC Software Engineering Software Quality Requirements and Evaluation Quality Requirements
Journal of Software Engineering and Applications, 2016, 9, 112-127 Published Online April 2016 in SciRes. http://www.scirp.org/journal/jsea http://dx.doi.org/10.4236/jsea.2016.94010 The Analysis and Proposed
More informationVO Software Engineering
Administrative Issues Univ.Prof. Dr. Peter Auer Chair for Information Technology Email: auer@unileoben.ac.at Lecture Thursday 10:15 11:45 Project Lab Montag 16:00 19:00 Literature Helmut Balzert, Lehrbuch
More informationRequirements Engineering
Dr. Michael Eichberg Software Engineering Department of Computer Science Technische Universität Darmstadt Software Engineering Engineering The following slides are primarily based on the contents of the
More informationCh 4: Requirements Engineering. What are requirements?
Ch 4: Engineering What are? Functional and non-functional The software document specification engineering processes elicitation and analysis validation management The descriptions of what the system should
More informationRequirements Engineering Process
Requirements Engineering Process Requirement A description of a service that the system is expected to provide and the constraints under which it must operate. 1 Requirement Types Functional Requirement
More informationRequirements Engineering
Requirements Engineering An introduction to requirements engineering Gerald Kotonya and Ian Sommerville G. Kotonya and I. Sommerville 1998 Slide 1 Objectives To introduce the notion of system requirements
More informationLecture 5: Requirements Specifications
Lecture 5: Requirements Specifications Why we need to write specifications Purpose and audience Choosing an appropriate size and formality Desiderata for Specifications Properties of good specifications
More informationRequirements Engineering. Contents. Functional requirements. What is a requirement?
Contents Ø Introduction 4 Ø Engineering Ø Project Management Ø Software Design Ø Detailed Design and Coding Ø Quality Assurance Engineering Ø What is a Requirement? Ø RE Activities Ø Documentation Ø RE
More informationBusiness Analysis for Practitioners - Requirements Elicitation and Analysis (Domain 3)
Business Analysis for Practitioners - Requirements Elicitation and Analysis (Domain 3) COURSE STRUCTURE Introduction to Business Analysis Module 1 Needs Assessment Module 2 Business Analysis Planning Module
More informationChapter 4 Objectives
Chapter 4 Objectives Eliciting requirements from the customers Modeling requirements Reviewing requirements to ensure their quality Documenting requirements for use by the design and test teams 4.1 The
More informationScenario-Based Analysis. Scenario-Based Analysis (example) Form analysis
Scenario-Based Analysis Scenario-Based Analysis (example) Provides a more user-oriented view perspective on the design and development of an interactive system. The defining property of a scenario is that
More informationIntroduction to Software Engineering
Introduction to Software Engineering Gérald Monard Ecole GDR CORREL - April 16, 2013 www.monard.info Bibliography Software Engineering, 9th ed. (I. Sommerville, 2010, Pearson) Conduite de projets informatiques,
More informationChapter 4 Requirements Engineering
Chapter 4 Requirements Engineering Chapter 4 Requirements Engineering Slide 1 Topics covered Why RE is hard... Functional and non-functional requirements Product vs. organizational vs. external requirements
More informationQuality Software Requirements By J. Chris Gibson
Quality Software Requirements By J. Chris Gibson The information contained within this document has been gathered from a variety of sources and practices observed by the development team at Protera Software
More informationSOFTWARE ENGINEERING. Software Specification Software Design and Implementation Software Validation. Peter Mileff PhD
Peter Mileff PhD SOFTWARE ENGINEERING Software Specification Software Design and Implementation Software Validation University of Miskolc Department of Information Technology Software Specification...
More informationRequirements Analysis
Requirements Analysis Software Requirements A software (product) requirement is is a feature, function, capability, or property that a software product must have. Software Design A software design is is
More informationSoftware specification and modelling. Requirements engineering
Software specification and modelling Requirements engineering Requirements engineering (RE) Requirements engineering is the process of establishing the services that a customer requires from a system and
More informationUNIT-II REQUIREMENTS ANALYSIS AND SPECIFICATION
UNIT-II REQUIREMENTS ANALYSIS AND SPECIFICATION The for a system are the descriptions of what the system should do the services that it provides and the constraints on its operation. User are statements,
More informationRequirements. CxOne Standard
Requirements CxOne Standard CxStand_Requirements.doc November 3, 2002 Advancing the Art and Science of Commercial Software Engineering Contents 1 INTRODUCTION... 1 1.1 OVERVIEW... 1 1.2 GOALS... 1 1.3
More informationPurpose and Structure of Requirements Specifications (following IEEE 830 Standard)
SEG3101 (Fall 2010) Purpose and Structure of Requirements Specifications (following IEEE 830 Standard) Gregor v. Bochmann, University of Ottawa Based on Powerpoint slides by Gunter Mussbacher (2009) with
More informationProduct. e ss. P roc. so get the right requirements. Garbage in garbage out,
If software is simply for automation, what would a washing machine be like? 1 RE Process Lawrence Chung Department of Computer Science The University of Texas at Dallas 2 RE Process: What is a Process?
More informationIntroduction to Software Specifications and Data Flow Diagrams. Neelam Gupta The University of Arizona
Introduction to Software Specifications and Data Flow Diagrams Neelam Gupta The University of Arizona Specification A broad term that means definition Used at different stages of software development for
More informationRequirements Validation and Negotiation
REQUIREMENTS ENGINEERING LECTURE 2017/2018 Joerg Doerr Requirements Validation and Negotiation AGENDA Fundamentals of Requirements Validation Fundamentals of Requirements Negotiation Quality Aspects of
More informationcopyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Software Engineering: A Practitioner s Approach, 6/e Chapter 7 Requirements Engineering copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student
More informationSE351a: Software Project & Process Management. 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa
SE351a: Software Project & Process Management W4.2: Requirements Engineering 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa SE351 Roadmap Introduction to Software Project Management Project Management
More informationVragen. Use case analysis. Use-Cases: describing how the user will Use cases
Vragen Use case analysis Welke problemen kunnen optreden bij het expliciet maken van het impliciete model bij conceptueel modelleren? Wat is het doel van elicitatie? Noem een aantal elicitatie technieken?
More informationSoftware Requirements Specification. <Project> for. Version 1.0 approved. Prepared by <author(s)> <Organization> <Date created>
Software Requirements Specification for Version 1.0 approved Prepared by Software Requirements Specification for Page 2 Table of Contents Revision
More informationRE Process. Lawrence Chung Department of Computer Science The University of Texas at Dallas
1 RE Process Lawrence Chung Department of Computer Science The University of Texas at Dallas 2 RE Process: What is a Process? Given input, transforms it into output Consist of a set of activities Process
More informationRecommended Practice for Software Requirements Specifications (IEEE)
Recommended Practice for Software Requirements Specifications (IEEE) Author: John Doe Revision: 29/Dec/11 Abstract: The content and qualities of a good software requirements specification (SRS) are described
More informationRequirements Validation and Negotiation
REQUIREMENTS ENGINEERING LECTURE 2015/2016 Eddy Groen Requirements Validation and Negotiation AGENDA Fundamentals of Requirements Validation Fundamentals of Requirements Negotiation Quality Aspects of
More informationReducing the costs of rework. Coping with change. Software prototyping. Ways to Cope with change. Benefits of prototyping
Coping with change Change is inevitable in all large software projects. Business changes lead to new and changed system requirements New technologies open up new possibilities for improving implementations
More informationData Quality Assessment Tool for health and social care. October 2018
Data Quality Assessment Tool for health and social care October 2018 Introduction This interactive data quality assessment tool has been developed to meet the needs of a broad range of health and social
More information(c) Addison Wesley Chapter 3. ! Interviewing customers and domain experts. ! Questionnaires. ! Observation. ! Study of documents and software systems
MACIASZEK, L.A. (2001): Analysis and System Design. Developing Information Systems with UML, Addison Wesley elicitation Domain Expert Customer Chapter 3 Determination Domain Knowledge Business Analyst
More informationSoftware Processes. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 4 Slide 1
Software Processes Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 4 Slide 1 Objectives To introduce software process models To describe three generic process models and when they may be
More informationThis tutorial also elaborates on other related methodologies like Agile, RAD and Prototyping.
i About the Tutorial SDLC stands for Software Development Life Cycle. SDLC is a process that consists of a series of planned activities to develop or alter the Software Products. This tutorial will give
More informationJoint Application Design & Function Point Analysis the Perfect Match By Sherry Ferrell & Roger Heller
Joint Application Design & Function Point Analysis the Perfect Match By Sherry Ferrell & Roger Heller Introduction The old adage It s not what you know but when you know it that counts is certainly true
More informationOverview of the course. User-Centred Design. Group. Practical issue. Writting the report. Project work. Fang Chen
Overview of the course User-Centred Design Fang Chen 6 lectures, 3 hr each. L 1: April 6, 9-12, user-centered design concept L2: April 14, 9-12, usability concept L3. user-centered requirement study L4.
More informationCMSC 435: Software Engineering Section 0201
CMSC 435: Software Engineering Section 0201 Atif M. Memon (atif@cs.umd.edu) 4115 A.V.Williams building Phone: 301-405-3071 Office hours Tu.Th. (11:00am-1:00pm) Don t wait, don t hesitate, do communicate!!
More informationLesson 06. Requirement Engineering Processes
Lesson 06 Requirement Engineering Processes W.C.Uduwela Department of Mathematics and Computer Science Objectives To describe the principal requirements engineering activities and their relationships To
More informationPrototyping. Lecture # 21
Prototyping Lecture # 21 1 Prototyping It is the technique of constructing a partial implementation of a system so that customers, users, or developers can learn more about a problem or a solution to that
More informationLecture 7 (3-April-2013)
SOFTWARE QUALITY ASSURANCE Lecture 7 (3-April-2013) Instructor: Mr. Natash Ali Mian Department of CS and IT Department of CS and IT The University of Lahore ` Switch off mobile phones during lectures,
More informationThe requirements engineering process
3 rd Stage Lecture time: 8:30-12:30 AM Instructor: Ali Kadhum AL-Quraby Lecture No. : 5 Subject: Software Engineering Class room no.: Department of computer science Process activities The four basic process
More informationIntro to Software Requirements
Intro to Software Requirements What question do software requirements answer? Who, what, when, where, why, how What is the system to do? Who are the system user groups? Business case tells us why (and
More informationREQUIREMENTS. Michael Weintraub Spring, 2016
REQUIREMENTS Michael Weintraub Spring, 2016 Unit Objective Understand what requirements are Understand how to acquire, express, validate and manage requirements Definitions A thing demanded or obligatory
More informationBuilding a New Rational Web Site with Rational Suite
Building a New Rational Web Site with Rational Suite by Christina Howe Director of Internet Services Rational Software In April of last year, Rational Software determined that its Web site no longer measured
More informationStandard Glossary of Terms used in Software Testing. Version 3.2. Foundation Extension - Usability Terms
Standard Glossary of Terms used in Software Testing Version 3.2 Foundation Extension - Usability Terms International Software Testing Qualifications Board Copyright Notice This document may be copied in
More informationBCS International Diploma in Consultancy Syllabus & Guidelines Version 1.2 December 2016
BCS International Diploma in Consultancy Syllabus & Guidelines Version 1.2 December 2016 This qualification is not regulated by the following United Kingdom Regulators - Ofqual, Qualification in Wales,
More informationUNIT II Requirements Analysis and Specification & Software Design
UNIT II Requirements Analysis and Specification & Software Design Requirements Analysis and Specification Many projects fail: because they start implementing the system: without determining whether they
More informationEXAM PREPARATION GUIDE
When Recognition Matters EXAM PREPARATION GUIDE PECB Certified ISO 9001 Lead Auditor www.pecb.com The objective of the PECB Certified ISO 9001 Lead Auditor examination is to ensure that the candidate possesses
More informationRequirements Engineering. Csaba Veres
Requirements Engineering Csaba Veres utline What is requirements engineering? Why is it important? How can you do it (properly)? an Requirements engineering, P11 overview quality evaluation (validation)
More informationHuman Error Taxonomy
Human Error Taxonomy The Human Error Taxonomy (HET) provides a structure for requirement errors made during the software development process. The HET can be employed during software inspection to help
More informationVendor: The Open Group. Exam Code: OG Exam Name: TOGAF 9 Part 1. Version: Demo
Vendor: The Open Group Exam Code: OG0-091 Exam Name: TOGAF 9 Part 1 Version: Demo QUESTION 1 According to TOGAF, Which of the following are the architecture domains that are commonly accepted subsets of
More informationSoftware Engineering - I
Software Engineering - I An Introduction to Software Construction Techniques for Industrial Strength Software Chapter 3 Requirement Engineering Copy Rights Virtual University of Pakistan 1 Requirement
More informationApplying ISO/IEC Quality Model to Quality Requirements Engineering on Critical Software
Applying ISO/IEC 9126-1 Quality Model to Quality Engineering on Critical Motoei AZUMA Department of Industrial and Management Systems Engineering School of Science and Engineering Waseda University azuma@azuma.mgmt.waseda.ac.jp
More informationLecture 8 Requirements Engineering
Lecture 8 Requirements Engineering Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte September 18, 2008 Lecture Overview
More informationSoftware Engineering Unit 4- Requirement Analysis and Specification
Software Engineering Unit 4- Requirement Analysis and Specification Requirement Engineering The process to gather the software requirements from client, analyze and document them is known as requirement
More informationMathematics and Computing: Level 2 M253 Team working in distributed environments
Mathematics and Computing: Level 2 M253 Team working in distributed environments SR M253 Resource Sheet Specifying requirements 1 Overview Having spent some time identifying the context and scope of our
More informationChapter 8 Software Testing. Chapter 8 Software testing
Chapter 8 Software Testing 1 Topics covered Introduction to testing Stages for testing software system are: Development testing Release testing User testing Test-driven development as interleave approach.
More informationSOFTWARE ARCHITECTURE & DESIGN INTRODUCTION
SOFTWARE ARCHITECTURE & DESIGN INTRODUCTION http://www.tutorialspoint.com/software_architecture_design/introduction.htm Copyright tutorialspoint.com The architecture of a system describes its major components,
More informationBCS Certificate in Requirements Engineering Syllabus
BCS Certificate in Requirements Engineering Syllabus Version 2.3 March 2015 Change History Any changes made to the syllabus shall be clearly documented with a change history log. This shall include the
More informationSOFTWARE ENGINEERING DECEMBER. Q2a. What are the key challenges being faced by software engineering?
Q2a. What are the key challenges being faced by software engineering? Ans 2a. The key challenges facing software engineering are: 1. Coping with legacy systems, coping with increasing diversity and coping
More informationEXAM PREPARATION GUIDE
When Recognition Matters EXAM PREPARATION GUIDE PECB Certified ISO 14001 Lead Auditor www.pecb.com The objective of the PECB Certified ISO 14001 Lead Auditor examination is to ensure that the candidate
More informationSpecifying and Prototyping
Contents Specifying and Prototyping M. EVREN KIYMAÇ 2008639030 What is Specifying? Gathering Specifications Specifying Approach & Waterfall Model What is Prototyping? Uses of Prototypes Prototyping Process
More information(Objective-CS605 Software Engeenring-II)
Which one of the following is NOT a useful indicator of software quality? Correctness Code size (Page 67) Maintainability Integrity Usability Which one of the following does not belong to a strategy for
More informationEXAM PREPARATION GUIDE
When Recognition Matters EXAM PREPARATION GUIDE PECB Certified ISO 22000 Lead Auditor www.pecb.com The objective of the Certified ISO 22000 Lead Auditor examination is to ensure that the candidate has
More informationSoftware Requirements Specification. <Project> for. Version 1.0 approved. Prepared by <author> <organization> <date created>
Software Requirements Specification for Version 1.0 approved Prepared by Copyright 2002 by Karl E. Wiegers. Permission is granted to use, modify, and distribute
More informationFundamentals: Software Engineering. Objectives. Last lectures. Unit 2: Light Introduction to Requirements Engineering
Fundamentals: Software Engineering Dr. Rami Bahsoon School of Computer Science University of Birmingham r.bahsoon@cs.bham.ac.uk Unit 2: Light Introduction to Requirements Engineering Dr R Bahsoon 1 Objectives
More informationVerification and Validation. Assuring that a software system meets a user s needs. Verification vs Validation. The V & V Process
Verification and Validation Assuring that a software system meets a user s needs Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 19,20 Slide 1
More informationSoftware Engineering
Software Engineering JUNBEOM YOO Dependable Software Laboratory KONKUK University http://dslab.konkuk.ac.kr Ver. 2.0 (2010.06) This lecture note is based on materials from Ian Sommerville 2006. Anyone
More informationProfessor Hausi A. Müller PhD PEng FCAE Department of Computer Science Faculty of Engineering University of Victoria
Professor Hausi A. Müller PhD PEng FCAE Department of Computer Science Faculty of Engineering University of Victoria http://www.engr.uvic.ca/~seng321/ https://courses1.csc.uvic.ca/courses/201/spring/seng/321
More informationDefining OAIS requirements by Deconstructing the OAIS Reference Model Date last revised: August 28, 2005
Defining OAIS requirements by Deconstructing the OAIS Reference Model Date last revised: August 28, 2005 This table includes text extracted directly from the OAIS reference model (Blue Book, 2002 version)
More informationRequirements. Chapter Learning objectives of this chapter. 2.2 Definition and syntax
Chapter 2 Requirements A requirement is a textual description of system behaviour. A requirement describes in plain text, usually English, what a system is expected to do. This is a basic technique much
More informationEXAM PREPARATION GUIDE
When Recognition Matters EXAM PREPARATION GUIDE PECB Certified OHSAS 18001 Lead Auditor www.pecb.com The objective of the PECB Certified OHSAS 18001 Lead Auditor examination is to ensure that the candidate
More informationWhat is the Joint Application Development (JAD) Process?
What is the Joint Application Development (JAD) Process? By Joy Matthews, Vice President, Pierson Requirements Group, Inc. jmatthews@piersonrequirementsgroup.com JAD is an Important Technique for Software
More informationVMware BCDR Accelerator Service
AT A GLANCE The rapidly deploys a business continuity and disaster recovery (BCDR) solution with a limited, pre-defined scope in a non-production environment. The goal of this service is to prove the solution
More informationfor TOGAF Practitioners Hands-on training to deliver an Architecture Project using the TOGAF Architecture Development Method
Course Syllabus for 3 days Expert led Enterprise Architect hands-on training "An Architect, in the subtlest application of the word, describes one able to engage and arrange all elements of an environment
More informationOG The Open Group OG TOGAF 9 Combined Part 1 and Part 2
The Open Group OG0-093 TOGAF 9 Combined Part 1 and Part 2 1 Set1, Part 1 QUESTION: 1 Which of the following TOGAF components was created to enable architects to design architectures addressing Boundaryless
More informationCertified Software Quality Engineer Preparation On Demand, Web-Based Course Offered by The Westfall Team
Certified Software Quality Engineer (CSQE) Preparation course is an on demand, web-based course design to be a comprehensive, in-depth review of the topics in the ASQ s Certified Software Quality Engineer
More informationEXAM PREPARATION GUIDE
EXAM PREPARATION GUIDE PECB Certified ISO/IEC 17025 Lead Auditor The objective of the PECB Certified ISO/IEC 17025 Lead Auditor examination is to ensure that the candidate possesses the needed expertise
More informationDATA PROTECTION POLICY THE HOLST GROUP
DATA PROTECTION POLICY THE HOLST GROUP INTRODUCTION The purpose of this document is to provide a concise policy regarding the data protection obligations of The Holst Group. The Holst Group is a data controller
More informationFor presentation at the Fourth Software Engineering Institute (SEI) Software Architecture Technology User Network (SATURN) Workshop.
For presentation at the Fourth Software Engineering Institute (SEI) Software Architecture Technology User Network (SATURN) Workshop. The authors can be reached at cb@mitre.org or ioannis @Mitre.org. In
More informationConcepts of Usability. Usability Testing. Usability concept ISO/IS What is context? What is context? What is usability? How to measure it?
Concepts of Usability Usability Testing What is usability? How to measure it? Fang Chen ISO/IS 9241 Usability concept The extent to which a product can be used by specified users to achieve specified goals
More informationEXAM PREPARATION GUIDE
EXAM PREPARATION GUIDE PECB Certified ISO 21500 Lead Project Manager The objective of the PECB Certified ISO 21500 Lead Project Manager examination is to ensure that the candidate has the knowledge and
More informationIntroduction to Software Engineering. ECSE-321 Unit 9 Architectural Design Approaches
Introduction to Software Engineering ECSE-321 Unit 9 Architectural Design Approaches Requirement Elicitation Analysis (Software Product Design) Architectural Design Detailed Design Architectural Design
More informationLecture 15 Software Testing
Lecture 15 Software Testing Includes slides from the companion website for Sommerville, Software Engineering, 10/e. Pearson Higher Education, 2016. All rights reserved. Used with permission. Topics covered
More informationUNIVERSITY OF CALGARY. Requirements Engineering for Software Product Lines. By Chethana Kuloor
UNIVERSITY OF CALGARY Requirements Engineering for Software Product Lines By Chethana Kuloor A PROJECT REPORT SUBMITTED TO THE FACULTY OF GRADUATE STUDIES IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR
More informationEXAM PREPARATION GUIDE
When Recognition Matters EXAM PREPARATION GUIDE PECB Certified ISO/IEC 20000 Lead Auditor www.pecb.com The objective of the Certified ISO/IEC 20000 Lead Auditor examination is to ensure that the candidate
More informationIncremental development A.Y. 2018/2019
Incremental development A.Y. 2018/2019 Incremental development Interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with
More information