1. R EQUIREMENTS AND SYSTEM ENGINEERING Week 4

2. O UTLINE System engineering Requirements elicitation Assignment

3. W HAT 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

4. S YSTEM 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. 5 Requirements definitions System design Sub-system development system integration System installation System evolution System decommissioning System modeling Concerned with how the system functionality is to be provided by the components of the system Implements all sub-system, identified during system design Specify what the system, should do and 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

6. W HAT 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)

7. T HE COMPOSITION AND DECOMPOSITION OF COMPLEX SYSTEM The decomposition continue until a large number of subsystems are developed F22 fighter aircraft – 152 subsystems

8. W HEN 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

9. E MERGENT 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.

10. E MERGENT 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

11. T HREE 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.

12. R E IN SE PROCESS MODELS

13. R E IN INCREMENTAL MODEL Each release adds more functionality

14. R E IN R ATIONAL UNIFIED PROCESS

15. O UTLINE System engineering Requirements elicitation Assignment

16. R EQUIREMENTS ENGINEERING IS MORE OF AN A RT THAN A S CIENCE Metrics Standards Tools Methods Techniques Templates Training Characteristics Communication Negotiating Language Problem Solving Expectations Assumptions Interpretation Judgement Perception Listening Skills Background Culture 20%80%

17. R EQUIREMENTS 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

18. G ATHERING 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

19. R EQUIREMENTS 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

20. T HE REQUIREMENTS ELICITATION PROCESS

21. C OLLECT 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

22. U SE 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

23. R EUSE 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

24. 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

25. 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

26. 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

27. 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.

28. 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

29. P ERSPECTIVES 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

30. O UTLINE System engineering Requirements elicitation Assignment

31. A SSIGNMENT Plagiarism issue Turnitin software E-mail for registration purpose

32. B USINESS 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

33. U SING 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

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