1 REQUIREMENTS By Harold Halbleib Requirements Management Identify, Specify, Track and Control Requirements Using a Standard Process About the author... Harold Halbleib has a degree in Electrical Engineering and ten years of experience in developing software for real-time, process control systems. He has spent the last 15 years developing Software Engineering tools, training engineers and working with hundreds of software companies around the world. His primary focus has been system analysis, requirements management, software design, code generation, reengineering, bug tracking, help authoring and programming for Macintosh, Windows and Linux. FORWARD We've all read the dire statistics where most IS-related projects are late, over budget, lacking in functionality or never delivered. Requirements drive the development process. Effective requirements management helps to control quality, cost, organization and schedule thus substantially improving your odds of a successful project. INTRODUCTION Requirements are the agreed upon facts about what an application or system must accomplish for its users. They are largely independent of the methods or notations used to analyze, design, implement or test the target application. The process of managing requirements can determine project success and is especially important for larger systems, outsourced projects or life critical software. Although primarily focused on software development, much of this discussion also applies to other activities like hardware development or systems engineering. A typical project will have hundreds or even thousands of requirements. Identifying and specifying those requirements will take time and effort, but the project payback can be enormous since it impacts every aspect of a project including design, implementation, testing, user documentation and project management. A solid foundation can substantially reduce project risk and increase the efficiency of the entire development effort.
2 Historical data shows that defects occurring in the requirement identification phase are costly to correct. Requirement defects include missing, incomplete, non-essential, ambiguous, overlapping or non-implemented requirements. A methodical approach to dealing with requirements can greatly reduce these deficiencies. Peers or customers can review written requirements to expose gaps in the understanding of what the project must accomplish. When developers spend time on design and implementation of non-essential or defective requirements, they re not just wasting time that delays the project. The added project bloat often increases future maintenance costs, slows the final product execution, complicates the user experience and makes the project more ridged and susceptible to errors during future enhancements. An accurate requirement list keeps the development effort clean and focused. Developers, testers, managers and users need an organized approach to identify, specify, track and control requirements. In the Definition section, we'll define requirements and common approaches to identify and group them. The Process section shows how requirements drive the project using a disciplined process. The Structure section suggests a collection of information retained for each requirement entry. The Traceability section discusses links and navigation through project deliverables. The Automation section illustrates how tools can streamline the process of managing requirements. DEFINITION A requirement statement is an unambiguous, testable statement defining processing, information, performance, error handling or capacity parameters about a condition or capability needed by a user to solve a problem or achieve an objective. System and product requirements are typically derived from market demands, quality, reliability, performance criteria and safety considerations. The first step in creating a list of requirements is to designate a definite boundary around the system to be considered. A simple picture or a few paragraphs of text can be a good starting point to ensure a clear, consistent mental picture. This boundary helps determine what belongs in the requirement list and what does not, since only externally visible aspects of the system need be included. Each requirement is uniquely named and becomes one entry in a hierarchy list of requirements. Since a requirement entry can express a system requirement, product requirement or UML style use case for a wide variety of software systems, the granularity, style and format of a requirement entry can vary greatly. It can be a simple, free format sentence or a more structured collection of data fields created with a user-defined template. The names of each requirement entry can form a hierarchical structure. Usually three levels of hierarchy is sufficient where the first part indicates the major functional area in which the requirement fits, the second part indicates the sub-functional area and the last part makes the name unique. This grouping of related requirements makes them easier to locate and helps to avoid incomplete or overlapping entries. When a large project is partitioned into subprojects and assigned to different developers, the topmost level in the hierarchy can be used as a namespace. Developers can work independently in different namespaces. With automated tools, it's easy to collapse and expand the requirement hierarchy, import or export
3 groups of requirements in a namespace or generate various reports from the requirement information in a specific namespace. For large, complex systems it's often advantageous to develop separate system level and product level Requirement documents. Each system requirement will likely reference multiple product requirements. The deliverables of development projects vary with each organization, but requirements should exist at the hub of any document structure. Document Structure of Typical Development Project For example, consider the design of a distributed process control system consisting of many individual products. A system requirement might specify timing constraints for communicating various types of messages from a process controller to an operator console connected on a data highway. The communication time depends on processing time required by each device and across the data highway itself. Several individual product requirements, one for each device and one for the data highway, would be needed to satisfy this system requirement.
4 A requirement statement answers the question, "What must the system do?" or "What must the product do?", but never, "How will the software do it?" Requirement statements are generally unaffected by the analysis, design and implementation methods and notations being used in the project. Specifying how something will be accomplished in a requirement will imply a design or worse yet an implementation. Different designs may satisfy the same requirements. A future redesign should have little impact on the underlying requirements. Design, technology and implementation issues are much more susceptible to change than true customer requirements. A good Requirements document provides a stable framework that maintains its integrity amidst those changes. Occasionally, indisputable design constraints are placed on the project such as conforming to an established architecture, industry standard or being compatible with an existing installed base of products. In these cases, prior architectural or design constraints do become true requirements of the new development project. A well-written requirement is testable. Avoid words like "most" and "some" and adverbs and adjectives like "quickly" and "robust" since these will make the requirement subject to interpretation and inherently non-testable. Be specific and watch for unstated assumptions. If a finite set of tests cannot prove that your system has passed or failed to satisfy the requirement, the requirement should be rewritten. Keep requirement statements short, focused and non-redundant. An important part of writing requirements is to develop a glossary for the project. Every organizational acronym, industry standard, piece of hardware, communication interface, protocol and role that users can perform should become a defined name in the glossary. Always use glossary names in requirement statements to keep them short and non-redundant. Once you develop a list of requirements, you want to review, refine and rewrite them to achieve quality definitions since they will drive team productivity during the design, implementation and testing activities that follow. A formal requirements review should ask these questions. Are all requirements included, within the scope and necessary for the software being developed? Is each requirement testable, feasible, independent, non-redundant and traceable? Has any term been used that's not defined in the glossary with a single, unambiguous meaning? Is there any unnecessary information that can be stripped from a requirement to make it as terse and design independent as possible? PROCESS Managing requirements is a process, not an event. That process starts at the conception of a project and continues until the developed system has been discontinued and is no longer supported. Later we'll discuss the structure of a requirement entry, where one field is its Status. The Status field indicates the state of progress of a requirement entry through its lifecycle. The Proposed state identifies a newly suggested requirement. Approved state indicates that a requirement will be implemented in the current project. Implemented state means the requirement has been implemented and is ready for testing. Validated state means
5 the requirement is completed. Postponed state indicates that the requirement won t be addressed by the current project. An automated tool can track the progress of each requirement through each state of its lifecycle. It should also allow you to add new states if your process requires it. For example, in a large system that includes system requirements and product requirements you might want several validation states like Unit Validation, Product Validation and System Validation. If you're outsourcing design and implementation, you might want an Out Source Validation and In House Validation state. To manage expectations and achieve your project schedule, you'll want to get most requirements nailed down very earlier in a development project. To reduce project risk, focus early prototyping efforts and detailed analysis on those aspects of a project with the biggest unknowns and most significant impact on a project's success. Requirements are identified and refined using numerous methods including customer surveys, brainstorming sessions, marketing analysis and engineering analysis activities. Data flow diagrams and entity-relation diagrams are commonly used tools during this phase of the project. These diagrams provide a communication medium between the analyst, customer and management. They increase understanding of the problem domain and help to surface the essential requirements for the project. Various methods and notations have been developed for analyzing systems and designing software. Structured analysis and design is popular in real-time, embedded systems. Desktop applications often use object-oriented analysis and design with notations like UML. Data modeling has been used for decades to design database systems. Some diagramming techniques like DFDs and Use Cases diagrams are used during the process of discovering requirements while others like structure charts, class diagrams and object diagrams are used during design to satisfy specified requirements. Later we'll discuss how traceability ties requirement entries to analysis diagrams, design diagrams, code files and test designs or procedures. STRUCTURE In its simplest form, a requirement list could be one-line definitions each having a unique entry name stored in a text file. Given the far-reaching impact of requirements and different needs of users, developers, managers and testers you'll likely want to gather a collection of information about each requirement entry. An automated tool makes this easy and should allow user-definable structure to that collection. Here's a standard structure that works well for most projects along with the meaning and intent of each field. The Priority field of a requirement can be set to Low, Medium or High to indicate its urgency. This field is used in queries to show which requirements should get immediate attention. The Status field indicates the progress of a requirement entry through its lifecycle as discussed earlier. The Author and Date fields are usually defaulted by an automated tool at the time the requirement entry is created. Use the Assigned field to indicate who has responsibility for implementing the requirement. You might want to add a Tester field if your organization has independent
6 product testers. The project manager or team leader can assign test responsibility for each requirement entry. The Category field lets you categorize each requirement entry. Category choices might include Interface, Functional, Data, Configuration, Performance, Reliability, Compatibility and Error. You ll probably need to adjust the choices of this field in the user-defined template to better fit the type of projects you do. The Effort field indicates in person days an estimate of the work required for implementation. Your organization needs to decide if that time estimate should include test effort, management overhead, technical documentation, etc. If you're grouping requirements into group and member entries, you may want to show the implementation time in each member entry and the rest of the overhead time in the group entry. The Summary field is a brief, single line summarization of the requirement. Often when scanning through requirements or generating management reports, you ll use this field rather than the full description. The Description field allows multiple lines of free format text where you can provide the explicit details of the requirement. Requirements sometimes evolve during implementation and as understanding of the system and the user s needs change. The Comments field is a place for anyone to express suggestions, describe problems or provide other feedback about a requirement. That information can later be considered when updating the Description field. TRACEABILITY The Parent field of a requirement entry can link to earlier documents that provide supplemental information, marketing specifications or engineering analysis. Documents later derived from the requirements are linked to the Child field. Requirements also link to each other to express a variety of relationships like inheritance, inclusion and extension. Links assist in user navigation of project information and can be transferred into generated reports. Each requirement can reference analysis models, design models, text specifications, code files, test files, HTML files, files created in other applications and other requirement entries. For example, a system requirement will reference each related product requirement in its Child field, while each of those product requirements will reference the system requirement in its Parent field. Each requirement entry will probably target one or more graphic models from its Child field that illustrate its design. Change control is an important aspect of requirements management. If requirements change which documents are affected? Who needs to be notified? How significant is the ripple effect throughout existing design, code and test procedures? Traceability improves risk assessment, project scheduling and change control. Traceability is a two-way street. If you're reading a requirement, the developer should be able to click to the related deliverables. Likewise, if you're looking at a design diagram of some type you should be able to see all related requirements. Traceability also provides a navigation mechanism that allows you to select a requirement of interest and then navigate to the related design diagrams, code files or test procedures in the project.
7 AUTOMATION During our discussion of defining and managing requirements with a well-defined process, using a structured collection of data for each entry and providing two-way traceability to other project deliverables, we've mentioned several automation opportunities. Gathering, refining, implementing, testing and using requirements to manage a project is a collaborative process involving many people. Collaboration without a defined process can lead to chaos. However, following a process without automation is labor intensive. Requirements management is an integral part of the development process that also includes system analysis and software design. Several tools are available to manage requirements including Rational Software's Requisite Pro, Telelogic's DOORs and Excel Software's WinA&D product. WinA&D combines requirements management with structured analysis and design, object-oriented methods and notations like UML, data modeling for database systems, code generation and reengineering. Screens from WinA&D shown below illustrate the automation of requirements management. An automated tool can enforce a structure on requirement entries and make it easy to comply by just filling in the blanks. The fields in that structure should be configurable by the user including allowable selections and data types of each field. Some fields like Author and Date can be automatically defaulted to reduce data entry time. Defining a Requirement Entry Requirement information should be viewable as standard or user-definable views and queries as illustrated in the Requirement Matrix below. Views determine what fields are shown in each column and their order. Queries define the selection criteria to determine
8 which requirements are shown. By choosing a specific view and query, different users can precisely access the data they need. Requirements Matrix Shows a Customized View of Requirement Information For example, system analysts and software architects will mostly be concerned with requirements in the Propose or Approved state so they'll use views and queries to reflect that. The project manager can view each requirement name and its priority, summary, status, estimated effort and whom it's assigned to. That subset of information can be extracted to a scheduling program or edited to balance the workload of team members. Software designers and programmers can narrow their view to those requirement entries in a specific namespace reflecting the functional area they're working on or to those requirements specifically assigned to them. Programmers can move requirements from the Approved to Implemented state. Testers can view and focus their effort on requirements assigned to them and as completed, change the status to Validated. In addition to displaying the precise information needed by each person, an automated tool makes that information exportable, importable, printable and reportable using built-in customizable features. For example, WinA&D includes a built-in scriptable reporting engine with full access to requirements, graphic analysis and design models, text specifications, dictionary information, code files and test procedures. Choose from dozens of standard reports or create customized reports with full control over the content and format.
9 HTML Report Generated from Product Requirements Notice that the automation has not only enforced a disciplined, streamlined process where requirements flow through predefined states, but it's also reduced the effort of getting updated project status. At any instant, the project manager can generate a formatted project report that reflects the current status of the project and highlights areas that need attention. SUMMARY Requirements are an integral part of the development proces connected through traceability with marketing specifications, analysis diagrams, design models, code files, test procedures and virtually every other project deliverable. The structure of product requirements usually lends itself well to organizing the design, implementation and test activities that follow. The mapping between system requirements and product requirements and between product requirements and design, implementation and test procedures will help ensure complete coverage and eliminate overlap. Each member of the development team uses a different subset of the requirement's information to do his or her job. An automated tool like WinA&D makes that information easily accessible through custom views and queries, user defined entry dialogs and scriptable HTML reports. Given the leveraging aspect of the requirement's foundation, a good set of requirements is your best weapon in controlling project quality, cost and schedule. Automated tools enforce a disciplined, streamlined process on that effort.
1 11 Tips to make the s definition process more effective and results more usable This article discusses what I believe are the key techniques for making s definition process repeatable from project to
TeamCompanion Solution Overview Visual Studio Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example
PHP Code Design PHP is a server-side, open-source, HTML-embedded scripting language used to drive many of the world s most popular web sites. All major web servers support PHP enabling normal HMTL pages
Chapter 2 Anatomy of an Enterprise Software Delivery Project Chapter Summary I present an example of a typical enterprise software delivery project. I examine its key characteristics and analyze specific
The Role of Requirements Traceability in System Development by Dean Leffingwell Software Entrepreneur and Former Rational Software Executive Don Widrig Independent Technical Writer and Consultant In the
project management applications... your way? 1 contents: Project Management Applications... Your Way? Introduction... 1 Business Teams Today are Overloaded with Data... 2 Desktop Tools Reign... 2 Managing
Computing Services Network Project Prepared By: Todd Brindley, CSN Project Version # 1.0 Updated on 09/15/2008 Version 1.0 Page 1 MANAGEMENT PLANNING Project : Version Control Version Date Author Change
Amir Tomer Amir Tomer is the Director of Systems and Software Engineering Processes at RAFAEL Ltd., Israel,with whom he has been since 1982,holding a variety of systems and software engineering positions,both
Using TechExcel s DevSuite to Achieve FDA Software Validation Compliance For Medical Software Device Development The FDA requires medical software development teams to comply with its standards for software
Basic Unified Process: A Process for Small and Agile Projects Ricardo Balduino - Rational Unified Process Content Developer, IBM Introduction Small projects have different process needs than larger projects.
Software Engineering G22.2440-001 Session 1 Sub-Topic 1 Requirements Definition & Management Processes and Tools Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute
Chapter 10 Practical Database Design Methodology and Use of UML Diagrams Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 10 Outline The Role of Information Systems in
Custom Software Development Approach Our approach to custom software development combines benefits from several standard development process models. We tend to have a well-defined, predictable and highly
Source Code Translation Everyone who writes computer software eventually faces the requirement of converting a large code base from one programming language to another. That requirement is sometimes driven
SOFTWARE REQUIREMENTS http://www.tutorialspoint.com/software_engineering/software_requirements.htm Copyright tutorialspoint.com The software requirements are description of features and functionalities
An Introduction to Requirements Management with Enterprise Architect By Sparx Systems All material Sparx Systems 2010 version 1.3 www.sparxsystems.com Sparx Systems 2010 Page 1 Trademarks Object Management
Software Engineering Session 3 Main Theme Requirements Definition & Management Processes and Tools Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical
Efficient Management of Tests and Defects in Variant-Rich Systems with pure::variants and IBM Rational ClearQuest Publisher pure-systems GmbH Agnetenstrasse 14 39106 Magdeburg http://www.pure-systems.com
Purpose The purpose of this document is to provide guidance on the practice of Modeling and to describe the practice overview, requirements, best practices, activities, and key terms related to these requirements.
August 2009 Lowering business costs: Mitigating risk in the software delivery Roberto Argento IBM Rational Business Development Executive Valerie Hamilton IBM Rational Solution Marketing Manager and Certified
Managing Agile Projects in TestTrack GUIDE Table of Contents Introduction...1 Automatic Traceability...2 Setting Up TestTrack for Agile...6 Plan Your Folder Structure... 10 Building Your Product Backlog...
JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2006 Vol. 5. No. 8, November-December 2006 Requirements Engineering Tasks Donald Firesmith,
Improve Quality and Decrease Time to Market with Better Requirements Management Requirements Engineering: Right Requirements, Right Products Nearly 20% of development cost is due to rework because of ill-defined
Approach Prepared By: Sanjay Seth Data Quality Assessment Approach-Review.doc Page 1 of 15 Introduction Data quality is crucial to the success of Business Intelligence initiatives. Unless data in source
The Software Lifecycle Examining the phases of large-scale software development projects Jeff Stephenson Software Lifecycles Software Engineering vs. Programming What you have done for our past assignments
j Microsoft Software Requirements, Third Edition Karl Wiegers and Joy Beatty Contents Introduction Acknowledgments xxv xxxi PART I SOFTWARE REQUIREMENTS: WHAT, WHY, AND WHO Chapter 1 The essential software
Verona: On-Time, On-Scope, On-Quality All project teams struggle to meet the potentially conflicting objectives of delivering ontime, with all committed features and with the highest levels quality. And
Convergence of Desktop Security and Management: System Center 2012 Endpoint Protection and System Center 2012 Configuration Manager Contents INTRODUCTION: UNDERSTANDING HOW ALIGNING DESKTOP SECURITY AND
Smarter Balanced Assessment Consortium Recommendation Smarter Balanced Quality Assurance Approach Recommendation for the Smarter Balanced Assessment Consortium 20 July 2012 Summary When this document was
3SL Requirements Definition and Management Using Cradle November 2014 1 1 Introduction This white paper describes Requirements Definition and Management activities for system/product development and modification
MCQ on Management Information System. Answer Key 1.Management information systems (MIS) 1. create and share documents that support day-today office activities 2. process business transactions (e.g., time
IV. Software Lifecycles Software processes and lifecycles Relative costs of lifecycle phases Examples of lifecycles and processes Process maturity scale Information system development lifecycle Lifecycle
Karen Lee How Application Lifecycle Management can address elearning Software Challenges Borland solutions for fast and flexible software delivery A Borland ASEAN White Paper August 2004 Karen Lee Borland
ScienceLogic vs. Open Source IT Monitoring Next Generation Monitoring or Open Source Software? The table below compares ScienceLogic with currently available open source network management solutions across
Introduction to Glossary Business B T O Metadata Primer Business Metadata Business rules, Definitions, Terminology, Glossaries, Algorithms and Lineage using business language Audience: Business users Technical
NASCIO EA Development Tool-Kit Solution Architecture Version 3.0 October 2004 TABLE OF CONTENTS SOLUTION ARCHITECTURE...1 Introduction...1 Benefits...3 Link to Implementation Planning...4 Definitions...5
Requirements Based Testing Process Overview 2009 Bender RBT Inc. 17 Cardinale Lane Queensbury, NY 12804 518-743-8755 firstname.lastname@example.org www.benderrbt.com The requirements-based testing (RBT) process addresses
Record-Level Access: Under the Hood Salesforce, Summer 15 @salesforcedocs Last updated: May 20, 2015 Copyright 2000 2015 salesforce.com, inc. All rights reserved. Salesforce is a registered trademark of
Software development White paper October 2007 The role of integrated requirements Jim Heumann, requirements evangelist, IBM Rational 2 Contents 2 Introduction 2 What is integrated requirements management?
Business white paper Best practices in project and portfolio management Practical advice for achieving greater value and business benefits Table of contents 3 Introduction 3 The importance of best practices
Information Technology Standard Commonwealth of Pennsylvania Governor's Office of Administration/Office for Information Technology STD Number: STD-INF003B STD Title: Data Modeling Basics Issued by: Deputy
Previews of TDWI course books are provided as an opportunity to see the quality of our material and help you to select the courses that best fit your needs. The previews can not be printed. TDWI strives
PARCC TECHNOLOGY ARCHITECTURE ARCHITECTURAL PRINCIPLES AND CONSTRAINTS SUMMARY Version 1.1 November 5, 2012 Architectural Principles and Constraints Summary REVISION HISTORY The following revision chart
System Development and Life-Cycle Management (SDLCM) Methodology Subject Type Standard Approval CISSCO Program Director A. PURPOSE This standard specifies content and format requirements for a Physical
Improve Your Process With Online Good Practices 1 Karl Wiegers Process Impact www.processimpact.com Most software developers are allergic to paper. As organizations improve their software development and
Chapter 10 Practical Database Design Methodology and Use of UML Diagrams Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 10 Outline The Role of Information Systems in
Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and
Software Development Life Cycle (SDLC) Supriyo Bhattacharjee MOF Capability Maturity Model (CMM) A bench-mark for measuring the maturity of an organization s software process CMM defines 5 levels of process
White Paper Requirements-Based Testing: Encourage Collaboration Through Traceability Executive Summary It is a well-documented fact that incomplete, poorly written or poorly communicated requirements are
Date: 7 th October 2010 Author: Guillaume FINANCE, Objet Direct Analyst & Consultant UML, the standard modelling language used in the field of software engineering, has been tailored to define a modelling
Books: Software Configuration Management 1. B. Bruegge and A. H. Dutoit, Object-Oriented Software Engineering: Using UML, Patterns, and Java (Chapter 13) Outline of the Lecture Purpose of Software Configuration
in collaboration with Project, Program & Portfolio Help Leading Firms Deliver Value Managing Effectively & Efficiently Through an Enterprise PMO Program & Portfolio : Aligning IT Capabilities with Business
Enhance visibility into and control over software projects IBM Rational change and release management software Accelerating the software delivery lifecycle Faster delivery of high-quality software Software
Effective Management of Static Analysis Vulnerabilities and Defects Introduction According to a recent industry study, companies are increasingly expanding their development testing efforts to lower their
Software Process for QA Basic approaches & alternatives CIS 610, W98 / M Young 1/7/98 1 This introduction and overview is intended to provide some basic background on software process (sometimes called
System Center Configuration Manager Software Update Management Guide Friday, 26 February 2010 Version 184.108.40.206 Baseline Prepared by Microsoft Copyright This document and/or software ( this Content ) has
Curriculum Certified Software Tester (CST) Common Body of Knowledge Control Procedures Problem Resolution Reports Requirements Test Builds Test Cases Test Execution Test Plans Test Planning Testing Concepts
RFP 1. Applications IT Architect Analyzes and designs the architecture for software applications and enhancements, including the appropriate application of frameworks and design patterns and the interrelationships
SUBJET Version: 1 Which of the following statements best describes Business nalysis? Business nalysis provides the reasoning for initiating a project. Business nalysis is the strategic part of the project
Business Process Modeling with Structured Scenarios Doug Rosenberg ICONIX Software Engineering, Inc. In 2008, based on our experience with a number of business process engineering projects over the last
Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software
LECTURE 1. SYSTEMS DEVELOPMENT 1.1 INFORMATION SYSTEMS System A system is an interrelated set of business procedures used within one business unit working together for a purpose A system has nine characteristics
Total Exploration & Production: Field Monitoring Case Study 1 Summary TOTAL S.A. is a word-class energy producer and provider, actually part of the super majors, i.e. the worldwide independent oil companies.
What is a life cycle model? Framework under which a software product is going to be developed. Defines the phases that the product under development will go through. Identifies activities involved in each
Nova Software Quality Assurance Process White Paper Atlantic International Building 15F No.2 Ke Yuan Yi Road, Shiqiaopu, Chongqing, P.R.C. 400039 Tel: 86-23- 68795169 Fax: 86-23- 68795169 Quality Assurance
In this Lecture you will Learn: Systems Development Methodologies What a systems development methodology is Why methodologies are used The need for different methodologies The main features of one methodology
Master Thesis Software Engineering Thesis no: MSE-2007:02 January 2007 Metrics in Software Test Planning and Test Design Processes Wasif Afzal School of Engineering Blekinge Institute of Technology Box
Lumension Endpoint Management and Security Suite (LEMSS): Patch and Remediation Version 7.0 SP1 Evaluation Guide September 2010 Version 2.4 Copyright 2010, Lumension, Inc. Table of Contents Lumension Endpoint
All-in-One Business Accounting Software VisionCore is the first.net Accounting and ERP software that is Connected, Customizable and Scalable. This software is a powerful, yet simple to use accounting and
Business Process Management In An Application Development Environment Overview Today, many core business processes are embedded within applications, such that it s no longer possible to make changes to
bu See What's Coming in Oracle Service Cloud Release Content Document August 2015 TABLE OF CONTENTS ORACLE SERVICE CLOUD AUGUST RELEASE OVERVIEW... 3 WEB CUSTOMER SERVICE... 4 Oracle Service Cloud Community
A Guide to the Business Analysis Body of Knowledge (BABOK Guide) Version 2.0 www.theiiba.org International Institute of Business Analysis, Toronto, Ontario, Canada. 2005, 2006, 2008, 2009, International
A Business Analysis Perspective on Business Process Management October 2013 Discussion Points! Why have Roles?! What is Business Analysis?! Who is the Business Analyst?! Business Analysis & Business Process
1 of 7 17.04.98 13:32 Software Requirements Specification The sub-sections : 1. What is a Software Requirements Specification 2. Why is a Software Requirement Specification Required 3. What is Contained
Training for the Business Analyst (BA122) Software Engineer s Workshop (SEW) Duration: 4 days CDUs (Continuing Development Units): 28 Description: A practical workshop covering the role of the Business-Systems
SAS Business Data Network 3.1 User s Guide SAS Documentation The correct bibliographic citation for this manual is as follows: SAS Institute Inc. 2014. SAS Business Data Network 3.1: User's Guide. Cary,
Bringing agility to Business Intelligence Metadata as key to Agile Data Warehousing 1 P a g e Table of Contents What is the key to agility in Data Warehousing?... 3 The need to address requirements completely....
Objective Software Project Measurements Slide 1 Fundamentals of Measurements Educational Objective: To review the fundamentals of software measurement, to illustrate that measurement plays a central role
PROJECT MANAGEMENT METHODOLOGY SECTION 3 -- PLANNING PHASE Table of Contents Introduction...3-1 Overview...3-1 The Process and the Project Plan...3-1 Project Objectives and Scope...3-1 Work Breakdown Structure...3-1
System Center Service Manager Vision and Planned Capabilities Microsoft Corporation Published: April 2008 Executive Summary The Service Desk function is the primary point of contact between end users and
Lumension Endpoint Management and Security Suite Patch and Remediation Module Evaluation Guide July 2012 Version 1.1 Copyright 2009, Lumension L.E.M.S.S:LPR - Table of Contents Introduction... 3 Module