SE351a: Software Project & Process Management. 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa
|
|
- Leonard Johns
- 5 years ago
- Views:
Transcription
1 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 Software Development Life Cycles Requirements Engineering Software Process & Project Metrics Software Project Planning Project Monitoring & Control Risk Management Software Quality Assurance 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 2
2 Outlines Fundamentals of Requirement Engineering Functional & Non-Functional Requirements Requirements Engineering Process Software Requirements Specification IEEE 830 SRS Standards Characteristics of Good SRS Document 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 3 Requirements Engineering Process build a prototype The problem/ Opportunity requirements elicitation develop Specification Review Management create analysis models 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 4
3 Requirements Engineering Process Elicitation determining what the customer requires! Analysis & negotiation understanding the relationships among various customer requirements and shaping those relationships to achieve a successful result Specification building a tangible model of requirements System Modeling building a representation of requirements that can be assessed for correctness, completeness, and consistency Validation & Verification reviewing the model Management identify, control and track requirements and the changes that will be made to them 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 5 Requirements Engineering Process(Roadmap) Process Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation & Verification Requirements Management 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 6
4 Requirements Elicitation Requirements elicitation is the activity during which software requirements are o discovered, articulated, and revealed from stakeholders o or derived from business/system requirements Sources may be business/system requirements documentation customers end-users domain specialists or market analysis 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 7 General Requirements Elicitation Process A general requirements process would be: 1) Identify all stakeholders who could be sources of requirements: o Users o Clients o Domain experts o DBAs, QAs, Programmers, etc. 2) Ask relevant questions to gain an understanding of the problem, issues and constraints 3) Analyze the information looking for conflicts, ambiguities, inconsistencies, problems or unresolved issues 4) Confirm your understanding of the requirements with the stakeholders 5) Create requirements statements 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 8
5 Requirements Elicitation: Problems Users Side Users may know what they want but are unable to articulate the requirements Users may not know what is technologically capable and may not consider what is possible Users and developers sometimes don't speak the same language No single user has all the answers, the requirements will most likely come from many sources 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 9 Requirements Elicitation: Problems Developers Side Developers may not have the necessary skills to get the requirements from the users Developers may be unable to develop a rapport or understanding of the users needs Developers sometimes don't appreciate the needs or concerns of the users Developers sometimes tend to bulldoze the users into agreeing on the developers requirements 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 10
6 User Involvement It is important that all stakeholders are involved, particularly important that the user be involved o usually, the users know what the system should do and have the domain expertise However, users also have problems articulating their needs! 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 11 Ways to get the User Involved Several methodologies/techniques to involve users Generally, 3 main styles 1. Consultative Design 2. Representative Design 3. Consensus Design 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 12
7 User Involvement Consultative Design Users are sources of information with little or no influence Decision making power is in the hands of the developers Techniques in this style are: Interviewing Structured meetings Steering committees Brainstorming 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 13 User Involvement: Representative Design User representatives are involved in the design formulation decision making Some techniques of this style are: Joint Application Design (JAD) through facilitated meetings attempts to have more user involvement in the development process Quality Functional Deployment (QFD) quality management technique that helps to understand the relative importance of solution elements to the customer 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 14
8 JAD: Participants Executive Sponsor: Attends opening and closing session Facilitator: Session leader, Mediator, resolve group conflicts Team: Users, Managers, Developers Scribe: Records meeting details, Action items, Publishes meeting proceedings Observer: Development team, Interested parties, Not active participants, Silent audience 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 15 JAD: Phases It evolves from a definite start to a clear finish 1. Project Definition It involves defining project purpose, scope, and objectives, identifying JAD team members, setting schedules, etc. 2. Research It involves gathering more details about the user requirements, exploring problem domain, etc. Then, the Session agenda is prepared listing what needs to be decided in the session. 3. Preparation It involves preparing everything needed for the session, such as visual aids, working document, flip charts, overhead transparencies 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 16
9 JAD: Phases 4. The Session This is the actual workshop session. JAD team members define business process, project requirements, etc. Agreed-upon decisions are documented as scribed notes and forms 5. The Final Document The scribed information from the session put into JAD document with signed approval form 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 17 How to Run Good JAD Meetings? Facilitation Good leader to manage the meetings Agenda setting and structure Must have meeting objectives Plan of action Documentation Scribe meeting details Group Dynamics Inspire creativity Compromise Speaking protocols 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 18
10 JAD: Implementation Guidelines Clear and appropriate objectives in JAD meetings Commitment Objective facilitator, one that has no stake Facilitator should avoid offering opinions Inputs from participants before JAD Establish rules Don t let developers dominate meetings Effective communication tools 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 19 JAD: Advantages Reduces function creep by 50%, reduced by another 10-25% when used with prototyping (Cline, 2000) Increases quality, Reduces cost and development lifecycle time High degree of user involvement Promotes cooperation, understanding and teamwork 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 20
11 JAD: Disadvantages Meetings can be costly Group sessions needs skilful running to ensure group they are productive and reach a consensus Workshops tie up stakeholders often for several days at a time Appears to have only been used effectively for smaller-medium groups 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 21 Supporting Techniques: Prototyping Prototypes can be used to elicit requirements by allowing the user to see what the Requirements Engineer thinks the user needs clarify poorly understood requirements. understand how the user actually does the work develop user interfaces 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 22
12 Supporting Techniques: Use-Cases A collection of scenarios that describe the thread of usage of a system Each scenario is described from the point-of-view of an actor a person or device that interacts with the software in some way Each scenario answers the following questions: What are the main tasks of functions performed by the actor? What system information will the actor acquire, produce or change? What information does the actor require of the system? Does the actor wish to be informed about unexpected changes 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 23 Use Case UML Diagram User scenarios are an extremely powerful mechanism Analyze risks <<include>> <<include>> Valuation Trader Price details <<extend>> Currency Exchange Financial Officer Capture deal Client DB TSX 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 24
13 Requirements Engineering Process(Roadmap) Process Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation & Verification Requirements Management 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 25 Requirements Analysis & Negotiation Requirements analysis is to determine conflicts, ambiguity, inconsistencies, missing requirements or extra requirements Negotiation between all stakeholders then occurs to arrive at a set of agreed upon requirements Requirements analysis and elicitation are very closely interleaved Paralysis Through Analysis When do you know you are done? Determine the appropriate level of abstraction and decomposition? 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 26
14 Organizing Requirements Part of analysis is to begin organizing the requirements into functional areas Some techniques: Use Scenarios (Use Cases) Function/Attribute Categorization Interrelationship Digraphs 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 27 Prioritizing Requirements There is never enough time to build the ultimate system Requirements will have to be prioritized to ensure that the most important requirements are completed o Prioritizing requirements play an important role in ensuring the success of the Requirements Engineering activity Techniques that can be used for this are Analytical Hierarchy Worth-Cost Graph 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 28
15 System Modeling An important part of the analysis effort is to model the system to understand what you are trying to build There are many system modeling techniques that can be used Structured Analysis and Structured Design (SASD) Object Oriented Analysis and Design (OOAD) System models supplement the natural language description of the software system System models can be developed at many levels of abstraction and detail It is important to determine the appropriate level 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 29 Requirements Engineering Process(Roadmap) Process Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation & Verification Requirements Management 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 30
16 Requirements Specification Requirements specification is the activity to record the requirements in one or more forms, such as Software Requirements Specification (SRS) document The requirements may be in o o o Remember: natural language, a formal language, or/and in a graphical form SRS is used to communicate the requirements to several people with various interest o customers, end-users, managers, designers, and system developers 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 31 Requirements Specification(Cont.) Recall that SRS can be many things to many people It describes what the system will be to the users Requirements definition Requirements specification Software specification It describes what kind of system the design team need to build It describes what kinds of things need to be tested for the testing team Client managers System end-users Client engineers Contractor managers System architects System end-users Client engineers System architects Software developers Client engineers (perhaps) System architects Software developers It is important to have a standardized template for SRS documents Provides consistency and a checklist to ensure that all things are considered You can create your own standard or use an industry standard, such as IEEE Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 32
17 Requirements Engineering Process(Roadmap) Process Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation & Verification Requirements Management 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 33 Requirements Validation & Verification It is the activity to check requirements for o omitted, extra, wrong, and inconsistent requirements There are two concerns 1. are the stated requirements correct? (validation) 2. are the requirements stated correctly? (verification) Also to ensure that all requirements follow stated quality standards Requirements Inspections Inspections can be very effective in discovering inconsistencies, omissions, commissions, ambiguities, etc. Checklists can be developed to ensure that the requirements are valid 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 34
18 Requirements Management It is a change control to manage changing requirements during the development of the software system Managing requirements is an ongoing process that occurs through out the project life-cycle Configuration control systems can be used to help in this endeavor 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 35 Requirements Engineering Process(Roadmap) Process Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation & Verification Requirements Management 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 36
19 Software Requirements Specification IEEE 830- SRS 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 37 Software Requirements Specification (Review) SRS contains a complete description of the functionality of the system to be built It contains both functional and non-functional requirements all the software requirements, diagrams, system models and other supporting information It is the end result of the Requirements Analysis phase It also serves as a baseline for the downstream phases 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 38
20 IEEE STD IEEE Recommended Practice for Software Requirements Specifications Example: IFCAP VISN/Integration Software Requirements Specification Draft 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 39 IEEE 830- SRS :General Form 1 Introduction 1.1 Purpose of SRS 1.2 Scope of product 1.3 Definitions, acronyms, abbreviations 1.4 References 1.5 Overview of the rest of the SRS 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 40
21 IEEE 830- SRS SRS (Cont.) 2 General description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 General constraints 2.5 Assumptions and dependencies 3 Specific Requirements Appendices 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 41 IEEE 830- SRS: Section Functional requirements Functional requirement Introduction Inputs Processing Outputs Functional requirement n Functional requirement n 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 42
22 IEEE 830- SRS: Section 3(Cont.) External interface requirements User interfaces Hardware interfaces Software interfaces Communications interfaces 3.3 Performance requirements 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 43 IEEE 830- SRS: Section 3(Cont.) Design constraints Standards compliance Hardware limitations Attributes Availability Security Maintainability Transferability/conversion 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 44
23 IEEE 830- SRS: Section 3(Cont.) Other requirements Database Operations Site adaptation 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 45 Roadmap Fundamentals of Requirement Engineering Functional, Non-Functional & Domain Requirements Requirements Engineering Process Software Requirements Specification IEEE 830 SRS Standards Good SRS Document 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 46
24 Characteristics of a Good SRS 1. Correct 2. Unambiguous, Precise, and Clear 3. Complete 4. Verifiable & Testable 5. Consistent 6. Deal only with the problem 7. Feasible 8. Modifiable 9. Traceable 10. Use an appropriate specification language 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 47 Correct Each requirement in the SRS is free from error Each requirement statement accurately represents the functionality required of the system to be built e.g., o A problem domain states that ABC system is to recover from a crash within 5 minutes, However, in the SRS Document R123: ABC will >>>> recover within 10 minutes <<<< the requirement is in error 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 48
25 Unambiguous, Precise, and Clear Rxxx: The user interface shall be windows-based Each requirement in the SRS is exact and unambiguous There is one and only one interpretation for every requirement Never assume that everyone will understand the requirement the way you do When writing the requirement, try to imagine that the requirement is to be given to ten people who are asked for their interpretation At least, all terms that may have multiple meanings should be defined in a glossary The meaning of each requirement is easily understood and is easy to read Requirement statements should be short, explicit, precise and clear 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 49 Complete Save to file (Y/N)?: Q An SRS is considered complete if all requirements have been defined, and the SRS is complete as a document this includes functional and non-functional requirements Usually, it is a difficult to determine, because it requires a complete understanding of the problem domain It is complicated by the implication that something is missing in the SRS, and it is not a simple process to find something that is not present by examining what is present 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 50
26 Complete(Cont.) However, it will be helpful to conform to the applicable SRS standard If a particular section is not applicable, the SRS should include the section number and an explanation of why it is not applicable All pages are numbered; all figures and tables are numbered, named and referenced; all terms and units of measure are provided; and all referenced material, and sections are present. This is completeness from a wordprocessing perspective No sections are marked (TBD) 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 51 Verifiable and Testable An SRS is verifiable if and only if every requirement statement is verifiable o A requirement is verifiable if and only if there is some finite cost-effective way in which a person or machine can check if the software product meets the requirements When looking at the testability of a requirement consider if it can be tested by actual test cases, analysis or inspection 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 52
27 Example An unverifiable requirement o 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 requirement o o 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 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 53 Consistent Inconsistency can manifest itself in various ways: Conflicting terms o Two terms are used in different contexts to mean the same thing e.g., The term in one requirement, prompt is used to denote a message to have a user input data, In another, the term cue is used to mean the same thing Conflicting characteristics o Two requirements in the SRS demand the software to exhibit contradictory attributes One requirement states all inputs shall be via a menu interface Another, states all inputs shall be via a command language 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 54
28 Consistent(Cont.) Temporal or logical inconsistency: o Two parts of the SRS might specify conflicting timing characteristics or logic, e.g., One requirement may state that interrupt A will only occur when condition B is running At the same time, another states that condition B will run after interrupt A occurs A logic inconsistency may be one requirement stating that the software will multiply the inputs, another requirement may state that the software will add the inputs o Inconsistency can also occur between the requirements and their source It is important to insure that the terminology used is the same as the terminology used in the source documents 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 55 Deal Only With The Problem Client and server shall communicate over an IP network The SRS should not obscured by design detail It should state "what" is required at the appropriate system level Avoid telling the designer "how" to do the job, instead state "what what" has to be accomplished It must be detailed enough to specify "what" is required, yet provide sufficient freedom so design is not constrained 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 56
29 Feasible Each requirement in the SRS can be implemented with the available techniques, and resources, and within the specified cost and schedule constraints Set performance bounds based on system requirements Not on state-of-the-art capability 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 57 Modifiable Modifiability is structure and style aspect of the SRS document Not directly related to the actual requirements themselves An SRS is modifiable if its structure & style are such that any necessary changes to the requirements can be made easily, completely, and consistently Modifiability of an SRS requires the following: The SRS has a coherent and easy-to-use organization, with a table of contents, an index, and cross-references if necessary o This will allow easy modification of the SRS in future updates The SRS should have no redundancy, o i.e., a requirement should not be in more than one place in the SRS 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 58
30 Traceable An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development or enhancement documentation Each requirement should be contained in a single, numbered paragraph so that it may be referred to in other documents Preferably the requirement should be titled as well Grouping of several requirements in a single paragraph should be avoided unless interrelated requirements cannot be separated and still provide clarity This will facilitate backward traceability to source documents and forward traceability to software design documents and test cases 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 59 Traceable(Cont.) Backward traceability implies that we know why every requirement in the SRS exists Forward traceability Each requirement explicitly references its source in previous documents implies that all documents that follow the SRS are able to reference the requirements This is done by each requirement in the SRS having a unique name or reference number 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 60
31 SRS: Language Issues It is recommended to use "shall" statements, a directive to express what is mandatory The use of "shall" requires a sense of commitment Unwillingness to make such a commitment may indicate that o the requirement, as currently stated, is too vague, or o stating "how" and not "what", etc. It is not recommended to use "will, should and may" unless absolutely necessary "Will" statements imply a desire, wish, intent or declaration of purpose "Should" or "may" are used to express non-mandatory provisions 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 61 Characteristics of a Good SRS 1. Correct 2. Unambiguous, Precise, and Clear 3. Complete 4. Verifiable & Testable 5. Consistent 6. Deal only with the problem 7. Feasible 8. Modifiable 9. Traceable 10. Use an appropriate specification language 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 62
32 Summary Fundamentals of Requirement Engineering Functional, Non-Functional & Domain Requirements Requirements Engineering Process Software Requirements Specification IEEE 830 SRS Standards Good SRS Document 13 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 63
Requirement 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 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 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 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 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 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 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 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 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 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 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 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 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 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 informationRequirements engineering
engineering Chapter 4 1 Engineering in the textbook 4.1 Functional and non-functional 4.2 The software document 4.4 engineering processes 4.5 elicitation and analysis 4.3 specification 4.6 validation 4.7
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 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 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 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 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 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 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 informationStandards for Writing Requirements and Specifications. Drs. Schesser & Simone BME 496 Capstone II
Standards for Writing Requirements and Specifications 1 Standards for Requirements Documents Based on the ANSI/IEEE Guide to Software Requirements STD 830-1984 Requirements use the shall language The system
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 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 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 informationThe software lifecycle and its documents
The software lifecycle and its documents Supplementary material for Software Architecture course B. Meyer, May 2006 Lifecycle models Origin: Royce, 1970, Waterfall model Scope: describe the set of processes
More informationIdentify the guidelines for system development. Discuss the purpose of the activities performed in the analysis phase
Discovering Computers 2010 Living in a Digital World Objectives Overview Define system development and list the system development phases Identify the guidelines for system development Discuss the importance
More informationBasics : 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 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 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 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 informationSofware Requirements Engineeing
Sofware Requirements Engineeing Three main tasks in RE: 1 Elicit find out what the customers really want. Identify stakeholders, their goals and viewpoints. 2 Document write it down (Requirements Specification).
More informationSystem Name Software Architecture Description
System Name Software Architecture Description Author Name Contact Details Version Date template 2011 Eoin Woods & Nick Rozanski 1 / 25 1. Version History Version Date Author Comments 1 July 08 Eoin Woods
More informationCPSC 444 Project Milestone III: Prototyping & Experiment Design Feb 6, 2018
CPSC 444 Project Milestone III: Prototyping & Experiment Design Feb 6, 2018 OVERVIEW... 2 SUMMARY OF MILESTONE III DELIVERABLES... 2 1. Blog Update #3 - Low-fidelity Prototyping & Cognitive Walkthrough,
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 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 informationRequirements Validation and Negotiation (cont d)
REQUIREMENTS ENGINEERING LECTURE 2017/2018 Joerg Doerr Requirements Validation and Negotiation (cont d) REQUIREMENTS VALIDATION AND NEGOTIATION Requirements Validation Techniques 2 Techniques Overview
More informationHITSP Standards Harmonization Process -- A report on progress
Document Number: HITSP 06 N 75 Date: May 4, 2006 HITSP Standards Harmonization Process -- A report on progress Arlington, VA May 4 th, 2006 0 What Was Done Reviewed obligations from federal contract Observed
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 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 9 Requirements Engineering II
Lecture 9 Requirements Engineering II Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte September 23, 2008 Announcements
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 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 informationEXAM PREPARATION GUIDE
EXAM PREPARATION GUIDE PECB Certified ISO 50001 Lead Auditor The objective of the PECB Certified ISO 50001 Lead Auditor examination is to ensure that the candidate has the knowledge and skills to plan
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 informationNick Rozanski Andy Longshaw Eoin Woods. Sold! How to Describe, Explain and Justify your Architecture
Nick Rozanski Andy Longshaw Eoin Woods Sold! How to Describe, Explain and Justify your Architecture Objectives of Today If you are an architect who has to produce an Architectural Description, then this
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 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 informationBuilding UAE s cyber security resilience through effective use of technology, processes and the local people.
WHITEPAPER Security Requirement WE HAVE THE IN-HOUSE DEPTH AND BREATH OF INFORMATION AND CYBER SECURIT About Us CyberGate Defense (CGD) is a solution provider for the full spectrum of Cyber Security Defenses
More informationElements of Requirements Style
Elements of Requirements Style Sponsored by: Karl Wiegers Principal Consultant, Process Impact www.processimpact.com Sponsor: Seilevel Published in 2012: Visual Models for Software Requirements Karl and
More information3Lesson 3: Web Project Management Fundamentals Objectives
3Lesson 3: Web Project Management Fundamentals Objectives By the end of this lesson, you will be able to: 1.1.11: Determine site project implementation factors (includes stakeholder input, time frame,
More informationEXAM PREPARATION GUIDE
When Recognition Matters EXAM PREPARATION GUIDE PECB Certified ISO 37001 Lead Auditor www.pecb.com The objective of the Certified ISO 37001 Lead Auditor examination is to ensure that the candidate possesses
More informationRequirements Gathering
Introduction to Requirements Gathering Prepared for: St. Edwards University Analysis, Modeling and Design MCIS6310 Dr. David Franke 6 June 2006 Copyright 2005-2006 Tyner Blain LLC 1 Outline 1. Overview
More information<PROJECT NAME> IMPLEMENTATION PLAN
IMPLEMENTATION PLAN Version VERSION HISTORY [Provide information on how the development and distribution of the Project Implementation Plan was controlled and tracked.
More informationQuality Software Requirements By J. Chris Gibson
Quality Software Requirements By J. Chris Gibson It has been stated that deficiencies in software requirements are the leading cause of failure in software projects. 1 If this is true then the contrapositive
More informationStakeholder Participation Guidance
Climate, Community & Biodiversity Alliance, Verra Stakeholder Participation Guidance Guidance to support stakeholder participation in design, implementation and assessment of policies and actions May 2018
More informationChapter 8: SDLC Reviews and Audit Learning objectives Introduction Role of IS Auditor in SDLC
Chapter 8: SDLC Reviews and Audit... 2 8.1 Learning objectives... 2 8.1 Introduction... 2 8.2 Role of IS Auditor in SDLC... 2 8.2.1 IS Auditor as Team member... 2 8.2.2 Mid-project reviews... 3 8.2.3 Post
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 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 informationISO/IEC INTERNATIONAL STANDARD. Systems and software engineering Requirements for designers and developers of user documentation
INTERNATIONAL STANDARD ISO/IEC 26514 First edition 2008-06-15 Systems and software engineering Requirements for designers and developers of user documentation Ingénierie du logiciel et des systèmes Exigences
More informationEXAM PREPARATION GUIDE
EXAM PREPARATION GUIDE PECB Certified ISO 39001 Lead Auditor The objective of the PECB Certified ISO 39001 Lead Auditor examination is to ensure that the candidate has the knowledge and skills to plan
More informationRequirements Specification with the IEEE 830 Standard
Requirements Specification with the IEEE 830 Standard Gregor v. Bochmann, University of Ottawa Based on Powerpoint slides by Gunter Mussbacher (2009) with material from: IEEE 830-1998 Standard, Daniel
More informationWhat is Software Architecture
What is Software Architecture Is this diagram an architecture? (ATM Software) Control Card Interface Cash Dispenser Keyboard Interface What are ambiguities in the previous diagram? Nature of the elements
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 informationISO/IEC INTERNATIONAL STANDARD
INTERNATIONAL STANDARD ISO/IEC 14143-2 First edition 2002-11-15 Information technology Software measurement Functional size measurement Part 2: Conformity evaluation of software size measurement methods
More informationRational Software White Paper
Traceability Strategies for Managing Requirements with Use Cases by Ian Spence, Rational U.K. and Leslee Probasco, Rational Canada, Copyright 1998 by Rational Software Corporation. All Rights Reserved.
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 information*ANSWERS * **********************************
CS/183/17/SS07 UNIVERSITY OF SURREY BSc Programmes in Computing Level 1 Examination CS183: Systems Analysis and Design Time allowed: 2 hours Spring Semester 2007 Answer ALL questions in Section A and TWO
More informationProfessional (CBAP) version 3
Certified Business Analysis Professional (CBAP) version 3 Amman Jordan July 29 th August 5 th, 2017 Instructor Mr. Tareq Al Nashawati Certified CBAP, PMP Table of Content 1 PROGRAM VALUE... 3 2 TARGET
More informationEXAM PREPARATION GUIDE
When Recognition Matters EXAM PREPARATION GUIDE PECB Certified ISO/IEC 27001 Lead Auditor www.pecb.com The objective of the Certified ISO/IEC 27001 Lead Auditor examination is to ensure that the candidate
More informationEuropean Commission. Immigration Portal Development Case. Date: 08/06/2007 Version: 1.0 Authors: Revised by: Approved by: Public: Reference Number:
EUROPEAN COMMISSION DIRECTORATE-GENERAL INFORMATICS Information systems Directorate European Commission Immigration Portal Development Case Date: 08/06/2007 Version: 1.0 Authors: Revised by: Approved by:
More informationUSER-CENTERED DESIGN KRANACK / DESIGN 4
USER-CENTERED DESIGN WHAT IS USER-CENTERED DESIGN? User-centered design (UCD) is an approach to design that grounds the process in information about the people who will use the product. UCD processes focus
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 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 informationNatural Language Specification
REQUIREMENTS ENGINEERING LECTURE 2017/2018 Dr. Jörg Dörr Natural Language Specification Most Requirements are Described in Natural Language Free Text (Prose) In Word In Excel (Tabular) In RM-Tools In Sys-ML
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 informationBCS Certificate in Requirements Engineering Extended Syllabus Version 2.5 May 2017
BCS Certificate in Requirements Engineering Extended Syllabus Version 2.5 May 2017 This professional certification is not regulated by the following United Kingdom Regulators - Ofqual, Qualification in
More information350 Index 2005 GOAL/QPC
Index abstract testing, 274 acceptance criteria, 270 acceptance tests, 270 activity diagrams, 113, 114, 174-175, 321 actor catalog, 144 actor description, 144 actor hierarchy, 148 actor map, 59, 114, 144,
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 informationPart 5. Verification and Validation
Software Engineering Part 5. Verification and Validation - Verification and Validation - Software Testing Ver. 1.7 This lecture note is based on materials from Ian Sommerville 2006. Anyone can use this
More informationUp and Running Software The Development Process
Up and Running Software The Development Process Success Determination, Adaptative Processes, and a Baseline Approach About This Document: Thank you for requesting more information about Up and Running
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 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 informationBusiness Requirements Document (BRD) Template
Business Requirements Document (BRD) Template Following is a template for a business requirements document (BRD). The document includes many best practices in use today. Don t be limited by the template,
More informationCompTIA Project+ (2009 Edition) Certification Examination Objectives
CompTIA Project+ (2009 Edition) Certification Examination Objectives DRAFT INTRODUCTION The Project + examination is designed for business professionals involved with projects. This exam will certify that
More informationData Governance Quick Start
Service Offering Data Governance Quick Start Congratulations! You ve been named the Data Governance Leader Now What? Benefits Accelerate the initiation of your Data Governance program with an industry
More informationFundamentals to Creating Architectures using ISO/IEC/IEEE Standards
Fundamentals to Creating Architectures using ISO/IEC/IEEE Standards What to Architect? How to Architect? IEEE Goals and Objectives Chartered by IEEE Software Engineering Standards Committee to: Define
More informationImplementing a Successful Data Governance Program
Implementing a Successful Data Governance Program Mary Anne Hopper Data Management Consulting Manager SAS #AnalyticsX Data Stewardship #analyticsx SAS Data Management Framework BUSINESS DRIVERS DATA GOVERNANCE
More informationSoftware Architecture
Software Architecture Does software architecture global design?, architect designer? Overview What is it, why bother? Architecture Design Viewpoints and view models Architectural styles Architecture asssessment
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 informationQA Best Practices: A training that cultivates skills for delivering quality systems
QA Best Practices: A training that cultivates skills for delivering quality systems Dixie Neilson QA Supervisor Lynn Worm QA Supervisor Maheen Imam QA Analyst Information Technology for Minnesota Government
More informationEXAM PREPARATION GUIDE
When Recognition Matters EXAM PREPARATION GUIDE PECB Certified ISO 22000 Lead Implementer www.pecb.com The objective of the Certified ISO 22000 Lead Implementer examination is to ensure that the candidate
More information<Project Name> Vision
Version [Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=infoblue) is included
More informationIBM s approach. Ease of Use. Total user experience. UCD Principles - IBM. What is the distinction between ease of use and UCD? Total User Experience
IBM s approach Total user experiences Ease of Use Total User Experience through Principles Processes and Tools Total User Experience Everything the user sees, hears, and touches Get Order Unpack Find Install
More informationVMware vcloud Air Accelerator Service
DATASHEET AT A GLANCE The VMware vcloud Air Accelerator Service assists customers with extending their private VMware vsphere environment to a VMware vcloud Air public cloud. This Accelerator Service engagement
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 informationSALESFORCE CERTIFIED TECHNICAL ARCHITECT
Certification Exam Guide SALESFORCE CERTIFIED TECHNICAL ARCHITECT Spring 18 2018 Salesforce.com, inc. All rights reserved. S ALESFORCE CERTIFIED TECHNICAL ARCHITECT CONTENTS About the Salesforce Certified
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 informationCreating an Intranet using Lotus Web Content Management. Part 2 Project Planning
Creating an Intranet using Lotus Web Content Management Introduction Part 2 Project Planning Many projects have failed due to poor project planning. The following article gives an overview of the typical
More information