r equirements and system engineering week 4. o utline system engineering requirements elicitation...
Post on 02-Jan-2016
225 Views
Preview:
TRANSCRIPT
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
5
Requirements definitions
System design
Sub-system development
systemintegration
Systeminstallation
System evolution
SystemdecommissioningSystem modeling
Concerned withhow the system functionalityis to be providedby the componentsof the system
Implements all sub-system,identified during system design
Specify whatthe system, should doand its desirable system properties
Put sub-systems together to make up a complete system
Change to correct errors in the original system req and to implement new req
Taking the system out of service
Put the system into operational use
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 developedF22 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 of the system itself
Deployment (Operation) deployment 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.
REQUIREMENTS ENGINEERING IS MORE OF AN ART THAN A SCIENCE
Metrics Standards Tools Methods Techniques Templates
Training Characteristics Communication Negotiating Language Problem Solving Expectations Assumptions Interpretation Judgement Perception Listening Skills Background Culture
20% 80%
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
Businessgoals
Systemconstraints
Problem to besolved
Establish objectives Understand background
Organisationalstructure
Applicationdomain
Existingsystems
Stakeholderidentification
Goalprioritisation
Domainknowledge
filtering
Organise knowledge
Stakeholderrequirements
Collect requirements
Domainrequirements
Organisationalrequirements
COLLECT REQUIREMENTS FROM MULTIPLEVIEWPOINTS
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 DRIVEREQUIREMENTS 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
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
top related