Requirements Engineering Training | Workshop www.tonex.com/training-courses/requirements-engineering-training/
Price: $2,999.00 Course Number: 912 Length: 3 Days
Requirements Engineering Training Workshop Requirements Engineering Training Workshop covers all aspects of requirements management and engineering. Requirements are the foundation for any system or produc. They determine WHAT the system or the product must do and eventually drive the system development. Requirements are usually derived from Concepts of Operations that are used to validate the system operation. Requirements are also used to determine [verify] if the project or the system team have built the system correctly. The requirements engineering manages the development and the process for all the activities needed to produce a set of complete and verifiable requirements. Requirements Engineering establishes what the customer requires from a system, software or product. The requirements engineering process includes: Feasibility study dealing with discover of if the current user needs be satisfied given the available technology, constraints and budget. Requirements analysis to find out what system stakeholders require from the system Requirements definition to define the requirements in a form understandable to the customer and stakeholders Requirements specification to define and specify all the requirements in detail Requirements may be functional or non-functional. Functional requirements describe system services or functions. Functional requirements process establishes the services and functions that the customer requires from a system and the constraints under which it operates and is developed. Non-functional requirements can be a constraint on the system or on the development process: a high-level abstract statement of a service or of a system constraint to a detailed. This is inevitable as requirements may serve a dual function: May be the basis for a bid for a contract – therefore must be open to interpretation May be the basis for the contract itself – therefore must be defined in detail Requirements engineering activities and process establish guidelines on creating and managing requirements. Requirements frequently start with a vague statement of intent. The first problem is to establish the boundary of investigation and, the scope of the 1/8
intended system or product. . Stakeholder involvement insures that the needs, concerns, problems, issues, constraints are prioritized and addressed during each stage of the development process. Stakeholders are all the organizations, groups, and individuals who will be affected by the system: planners users anyone or any organization who may be the operators maintainers users of the system Requirements engineering process includes a set of activities that will produce requirements for the system and related sub-systems. EIA 632 (Processes for Engineering a System). The systems engineering standard, defines “requirement” as “something that governs what, how well, and under what conditions a product will achieve a given purpose.” Requirements define the functions, performance, and environment of the system under development to a level that can be built: EIA 632 (SAE EIA 632) Standard was developed as a joint project of the EIA and INCOSE. Electronic Industries Alliance (EIA) and the International Council on Systems Engineering (INCOSE). This effort was chartered by the G-47 Systems Engineering Committee of EIA and has been designed as Project PN-3537. this Standard has been approved by the EIA Engineering Department Executive Committee. Does the system do WHAT it is supposed to do as described and needed by the stakeholders? – These are Functional requirements. These are Performance requirements: How well does the system do its functions? Environmental and Non-Functional requirements: Under what conditions does the system have to work and meet its performance goals (environmental, reliability, security and availability)?
2/8
Requirements Engineering Training Workshop Objectives: To introduce the notion of requirements engineering and requirements engineering process To introduce Feasibility study, Requirements analysis Find out what system stakeholders require from the system and Requirements specification Define the requirements in detail To explain why requirements at different levels of detail are needed To describe how the system requirements document may be organised To describe the requirements validation process To explain why requirements evolve during the lifetime of a system To write and manage requirements To learn techniques to rewrite the bad and misleading requirements
Course Agenda Introduction to Requirements and Requirements Engineering Introduction to Systems Engineering What is Requirements Engineering? Quality of Requirements Stakeholder Involvement Requirements Lifecycle Requirements Traceability Analysis and Modeling Testing and Integration Requirements Verification and Validation Mapping Requirements from Problem to Solution Domains Effective requirements management Principles of requirements definition and management Best practices for requirements engineering Requirements Baselining Requirements Engineering Framework The Requirements Engineering Process Requirements and the Business Context 3/8
Hierarchy of requirements Stakeholders in the requirements process Eliciting and Documenting Requirements Requirements Elicitation Interviewing for Requirements Use of models in Requirements Engineering Requirements Documentation Requirements Analysis Analyzing and Negotiating Requirements Requirements Validation and Verification Requirements Management Requirements Engineering and System Views Process View Deliverable View pertinent information for RFPs, SEMPs, ConOps, etc Checklist View Project View SE process applies Activities in the Requirements Engineering Develop requirements Write and document requirements Check completeness Analyze, refine, and decompose requirements Validate requirements Manage requirements Basic Requirements Engineering and Management Techniques for drawing out stakeholder needs, goals, requirements, constraints, priorities, normal operations, and preferences Initial needs assessment leading to the development of requirements .Elicitation Stakeholder Analysis Interviews and Workshops Observation Creativity Analysis Kano Specification Use Cases and ConOps BPMN Verification Validation Prototypes 4/8
Inspection Testing Demo Change management Version control Customer acceptance and validation Elicitation Techniques Interviews and Focus groups Questionnaires, surveys and Brainstorming Role play Review incident reports, enhancement requests and Joint authorship Benchmark – similar or competing systems Prototype Throw-away Evolutionary Process for Requirements Engineering Value of Systems Engineering Value of Requirements Engineering Customer Requirements Functional Requirements Performance Requirements Design Requirements Derived Requirements Allocated Requirements Concept of Operations(ConOps) System Requirements Integration and Verification System Validation Project Planning Project Monitoring and Control High-level identification of user needs and system capabilities Project stakeholders Stakeholder agreement Interrelationships and roles and responsibilities Shared understanding by system owners, operators, maintainers, and developers who, what, why, where, and how of the system and product Agreement on key performance measures Plan for how the system will be validated Developing Systems Input Requirements and Derived Requirements Acceptance Criteria and Qualification Strategy Generic Process Introduction Development in the Context of Change 5/8
System Modeling for Requirements Engineering Requirements Engineering and System Modeling Use Cases and Actors Data Flow Diagrams Entity-Relationship (E-R) Diagrams Statecharts Object-Oriented Approaches DoDAF and NAF Viewpoint Methods The UML and SysML Notations Formal Methods Model Based System Engineering (MBSE) and Requirements Engineering Managing, Writing and Reviewing Requirements System Life Cycle The systems engineering process Development of system architecture and detail design The Origin of Requirements Concept of the system boundary The modeling boundary Managing Requirements Validating Requirements Requirements traceability Baselines and their use The waterfall vs. agile life cycle paradigm Structuring Requirements Requirements Engineering in the Problem Domain Identify Stakeholders Operational and Use Scenarios Scoping the System Derive Requirements Allocated Requirements Requirements Engineering in the Solution Domain Stakeholder Requirements mapped to System Requirements System Requirements Requirements to Subsystems Traceability Metrics for Traceability Requirements Engineering Management Requirements Management Planning Monitoring Changes Development Relationship to design 6/8
Relationship to baselines Types of Requirements Differences between requirements for hardware, software, services Non-functional requirements Quality of Requirements Requirements Analysis Context analysis Operational Concept Description Verification requirements development “TBDs” Requirements and Requirements Specifications Requirements Flowdown into Specifications Requirements Engineering Gates and Cross-Cutting Activities Stakeholder Involvement Elicitation Project Management Practices Risk Management Metrics Configuration Management Project Process Improvement Decision Gates Decision Support/Trade Studies Technical Reviews Traceability Working with Requirements – Deliverable Checklist Are all the bases covered? Is there a definition of all the major system functions? With each function of the system, is there a set of requirements that describes: what the function does, who is assigned to do it, and under what conditions [e.g. environmental, reliability, and availability.] Are all terms, definitions, and acronyms defined? Are all supporting documents such as standards, concept of operations, and others reference Does each requirement have a link [traceability] to a higher level requirement of a user-specified need? Is each requirement concise, verifiable, clear, feasible, necessary, unambiguous, and technology independent? Are all technology dependent requirements identified as constraints? Does each requirement have a method of verification defined? Has the trace from requirements to hardware and software components been checked and verified? Working with requirements and requirement types 7/8
Functional Performance Enabling Data Interface Environmental Non-functional [reliability, availability, safety, and security].
8/8