REQUIREMENTS AND SYSTEM ENGINEERING Week 4 OUTLINE System

REQUIREMENTS AND SYSTEM ENGINEERING Week 4

OUTLINE System engineering Requirements elicitation Assignment

WHAT IS SYSTEM ENGINEERING An interdisciplinary approach and means to enable the realization of successful systems. Focuses on defining customer needs and required functionality, documenting requirements then proceeding with the design synthesis and system validation while considering the complete problem Operations Performance Test Manufacturing Cost and schedule Training and support Disposal Consider both the business and technical needs -> providing a quality product that meets the user needs

SYSTEM ENGINEERING PRINCIPLES INCOSE 1993 Know the problem, know the customer and know the consumer Use effectiveness criteria based on needs to make the system decisions Establish and manage requirements Identify and assess alternatives so as to converge on a solution Verify and validate requirements and solution performance Maintain the integrity of the system Use an articulated and documented process Manage against a plan

Specify what the system, should do and its desirable system properties Taking the system out of service Requirements definitions System design Concerned with how the system functionality is to be provided by the components of the system System modeling Change to correct errors in the original system req and to implement new req System evolution Implements all sub-system, identified during system design Sub-system development System decommissioning System installation system integration Put sub-systems together to make up a complete system Put the system into operational use 5

WHAT IS SYSTEM Wikipedia - a set of entities, real or abstract, comprising a whole where each component interacts with or is related to at least one other component and they all serve a common objective. IEEE - a collection of components organized to accomplish a specific function or set of functions US Air Force - an integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective A set of interrelated components which interact with one another in an organized fashion toward a common purpose (NASA systems engineering handbook)

THE COMPOSITION AND DECOMPOSITION OF COMPLEX SYSTEM The decomposition continue until a large number of subsystems are developed F 22 fighter aircraft – 152 subsystems

WHEN THE JOB IS DONE Distribution and partitioning of functionality are optimized – overall functionality with minimal costs and maximum flexibility Each subsystem can be defined, designed and built by a small team Each subsystem can be manufactured within the physical constraints and technologies of the available manufacturing processes Each subsystem can be reliably tested as a subsystem

EMERGENT PROPERTIES Properties of the system AS A WHOLE Not determined solely from the properties of the system parts but also from the system’s structure Emergent properties reflect the business requirements Examples A bicycle has the emergent property of being a transportation system when the parts are assembled in the right way. A mobile phone has the emergent property of being a communication device.

EMERGENT NON-FUNCTIONAL PROPERTIES Important emergent properties of a system are Performance Reliability Safety Security Usability Some or all of these properties are usually more important than detailed system functionality

THREE PHASES IN SE LIFE CYCLE Definition (Concept) definition of the requirements for a system Development (Production) development Deployment (Operation) deployment of the system itself of the system in an operating environment Any SE project must do RE. RE process, and its place in the whole SE process is affected by the process model we follow.

RE IN SE PROCESS MODELS

RE IN INCREMENTAL MODEL Each release adds more functionality

RE IN RATIONAL UNIFIED PROCESS

OUTLINE System engineering Requirements elicitation Assignment

REQUIREMENTS ENGINEERING IS MORE OF AN ART THAN A SCIENCE 20% 80% Metrics Standards Tools Methods Techniques Templates Training Characteristics Communication Negotiating Language Problem Solving Expectations Assumptions Interpretation Judgement Perception Listening Skills Background Culture

REQUIREMENTS ELICITATION The process through which to Discover, reveal, articulate, and understand the problem to be solved, the system services, the required performance of the system, hardware constraints, and so on Requirements discovery, requirements acquisition

GATHERING INFORMATION FROM … Stakeholders Interviews and discussions with stakeholders Observing users at work Scenario analysis of user tasks Documentation Documents that describe current or competing products Problem reports and enhancement requests for a current system Marketing surveys and user questionnaires External sources Other companies, vendors, publications, seminars, workshops, on-line data services

REQUIREMENTS ELICITATION IS A CHALLENGE ACTIVITY “Lack of User Input” is the most common factor of failed or challenged projects People find it hard to describe knowledge they regularly use Requires collaborations of people with different backgrounds A variety of stakeholders A number of requirements elicitation techniques Analysts should identify a set of appropriate techniques to elicit requirements proactively

THE REQUIREMENTS ELICITATION PROCESS

COLLECT REQUIREMENTS FROM MULTIPLE VIEWPOINTS If the requirements are collected from a single viewpoint, it is unlikely meet other stakeholders requirements Collecting requirements from multiple viewpoints is a useful way to prioritize requirements Identified viewpoints can be used to help organize requirements elicitation and organization in the requirements specification

USE BUSINESS CONCERNS TO DRIVE REQUIREMENTS ELICITATION –GOAL ORIENTED APPROACH If a system is to be useful, it must contribute to the key concerns of the business (business objective). If the concerns are identified and used as drivers of the requirements elicitation process, there will be higher confidence that the system will meet real organization needs Making the business concerns explicit helps to focus and clarify these goals

REUSE REQUIREMENTS Reuse involves taking the requirements which have been developed for one system and using them in a different system Saves time and effort, and reduces risk Studies have shown that similar systems can re-use up to 80% of the requirements Reused requirements have already been analyzed and validated in other systems Reused requirements have a better chance of being understood by all the stakeholders. Requirements reuse may lead to additional reuse in other lifecycle activities Currently, requirements reuse is an informal process but more systematic reuse could lead to larger cost savings

ELICITATION TECHNIQUES Requirements development is an intensive interaction process between stakeholders and analysts The elicitation techniques can be classified based on the means of interaction Conversational Observational Analytic Synthetic

Conversational methods A means of verbal communication between two and more people, e. g. interview, workshop, focus groups, brainstorming, etc. Practical and efficient to collect non-tacit knowledge Labor intensive, and challenge to facilitate the elicitation session

Observational methods A means of developing a rich understanding of the application domain by observing human activities e. g. observation, ethnographic study, protocol analysis, etc. Tacit requirements elicitation, understanding complex societies rather than making judgements Longitudinal studies

Analytic methods A means of exploring the existing documentation or knowledge and acquire requirements from a series of deductions e. g. documentation studies, requirements reuse, laddering, card sorting, etc. A complementary way to deduct and reuse knowledge Requirements are captured from other sources, e. g. expert knowledge, documents, etc.

Synthetic methods A means of combining conversation, observation, and analytic techniques into one e. g. scenarios, storyboards, prototyping, JAD/RAD session, etc. Good cues for requirements recognition Harmonize the requirements stage with other stages

PERSPECTIVES OF METHODS SELECTION Requirements abstraction level Generic problem analysis Specific product description Requirements source Human being Other environments • Communication obstacles National culture Organizational culture Individual cognitive limitation across time and space Requirements certainty Well-structured problem domain Unstructured problem domain

OUTLINE System engineering Requirements elicitation Assignment

ASSIGNMENT Plagiarism issue Turnitin software E-mail for registration purpose

BUSINESS MODELING Purpose To understand the structure and dynamics of the existing organization To ensure that customers, end users and developers have a common understanding of the organization To understand how to deploy new systems to facilitate productivity and which existing systems may be affected by that new system

USING SE TECHNIQUE UML – graphical language for visualizing, specifying, constructing and documenting the artifacts of software systems Business use case model Meet with customer to negotiate contract terms Actors : customer, employee, software developers Business object model Describes the entities and how they interact to deliver the functionality necessary to realize the business use case

Actor-circle icon – actor within the business process FROM BUSINESS MODEL TO SYSTEM MODEL Business entity or something workers produce Businmess Business use case model Business object model Business level Use case model Design model System modeling