Requirements and system engineering

1. Requirements and system engineering Week 4

2. Outline • System engineering • Requirements elicitation • Assignment

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

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

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

7. The composition and decomposition of complex system The decomposition continue until a large number of subsystems are developed F22 fighter aircraft – 152 subsystems

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

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

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

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

12. Re in se process models

13. Re in incremental model Each release adds more functionality

14. Re in Rational unified process

15. Outline • System engineering • Requirements elicitation • Assignment

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

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

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

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

20. The requirements elicitation process

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

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

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

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

30. Outline • System engineering • Requirements elicitation • Assignment

31. Assignment • Plagiarism issue • Turnitin software • E-mail for registration purpose

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

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

34. Actor-circle icon – actor within the business process From business model to system model Businmess Business entity or something workers produce Business use case model Business object model Business level Use case model Design model System modeling