Se6162 analysis concept and principles


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Se6162 analysis concept and principles

  1. 1. 1 IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 1 SE6162 Software Engineering Yani Widyani Departemen Teknik Informatika Institut Teknologi Bandung IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 2 Analysis Concept and Principles • Requirement analysis • Requirement elicitation • Analysis principles • Specification and specification review IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 3 Requirement Analysis “I know you believe you understand what you think I said, but I am not sure that you realize that what you heard is not what I meant” IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 4 Requirement Analysis • Software engineering task that bridges the gap between system level requirements engineering and software design. • Provides software designer with a representation of system information, function, and behavior that can be translated to data, architectural, and component-level designs. • Five area of effort (phases): – Problem recognition – Evaluation and synthesis (focus is on what not how) – Modeling – Specification – Review IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 5 Requirement Elicitation • Most commonly technique used: – Meeting – Interview • Initiating the Process – Asking context-free question: • Who is behind the request of this work • Who will use the solution • What will the economic benefit of a successful solution • Is there another source for the solution that you need – “He who asks a question is a fool for five minutes; he who does not ask a question remains a fool forever” (chinese proverb) IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 6 Req. Elicitation (2) – Next set of questions to gain better understanding of customer’s perceptions: • How would you characterize “good” output • What problem(s) will this solution address • Can you show me the environment in which the solution will be used • Will special performance issues or constraints affect the way the solutions approached – Final questions focused on the effectiveness of the meeting: • Are you the right person to answer • Are my questions relevant to the problem you have • Am I asking too many questions • Can anyone else provide additional information • Should I be asking you anything else These questions (and others) will help to “break the ice”…..
  2. 2. 2 IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 7 Req. Elicitation (3) • Do not only use the Q&A techniques – Only for the first encounter – Replace by the meeting that combines elements of: • Problem solving • Negotiation • Specification • Another techniques: – FAST (Facilitated Application Specification Techniques) – QFD (Quality Function Deployment) IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 8 Req. Elicitation (4) • FAST encourages the creation of a joint team of customers and developers who work together – Meeting held at neutral site, attended by both software engineers and customers. – Rules established for preparation and participation. – Agenda suggested to cover important points and to allow for brainstorming. – Meeting controlled by facilitator (customer, developer, or outsider). – Definition mechanism (flip charts, stickers, electronic device, etc.) is used. – Goal is to identify problem, propose elements of solution, negotiate different approaches, and specify a preliminary set of solution requirements. IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 9 Req. Elicitation (5) • QFD – Translates customer needs into technical software requirements – Identified three types of requirement: • Normal requirements (must be present in product for customer to be satisfied) • Expected requirements (things like ease of use or reliability of operation, that customer assumes will be present in a professionally developed product without having to request them explicitly) • Exciting requirements (features that go beyond the customer's expectations and prove to be very satisfying when they are present) – In meeting with the customer: • Function deployment is used to determine the value of each function required for system • Information deployment identifies data objects and events produced and consumed by the system • Task deployment examines the behavior of product within it environment • Value analysis is used to determine the relative priority of requirements during function, information, and task deployment IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 10 Req. Elicitation (6) • As requirements are gathered, the software engineer can create: – Scenarios that describe how the product will be used in specific situations called use-cases – narratives that describe the role of an actor (user or device) as interaction with the system occurs. • Use-cases are designed from the actor's point of view. • Not all actors can be identified during the first iteration of requirements elicitation, but it is important to identify the primary actors before developing the use-cases. IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 11 Analysis Principles • Operational principles: – The information domain of the problem must be represented and understood. – The functions that the software is to perform must be defined. – Software behavior must be represented. – Models depicting information, function, and behavior must be partitioned in a hierarchical manner that uncovers detail. – The analysis process should move from the essential information toward implementation detail. IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 12 Analysis Principles (2) • Guiding principles [DAV95a]: – Understand the problem before you begin to create the analysis model – Develop a prototypes that enable a user to understand how human-machine interaction will occur – Record the origin of and the reason for every requirement – Use multiple views for requirements – Rank requirements – Work to eliminate ambiguity
  3. 3. 3 IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 13 Analysis Principles (3) • Information domain: – Encompasses all data objects that contain numbers, text, images, audio, or video. – Information content or data model (shows the relationships among the data and control objects that make up the system) – Information flow (represents the manner in which data and control objects change as each moves through the system) – Information structure (representations of the internal organizations of various data and control items) IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 14 Analysis Principles (4) • Modeling: – Data model (shows relationships among system objects) – Functional model (description of the functions that enable the transformations of system objects) – Behavioral model (manner in which software responds to events from the outside world) IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 15 Analysis Principles (5) • Partitioning: – Process that results in the elaboration of data, function, or behavior. – Horizontal partitioning is a breadth-first decomposition of the system function, behavior, or information, one level at a time. – Vertical partitioning is a depth-first elaboration of the system function, behavior, or information, one subsytem at a time IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 16 Software Prototyping • Selecting the prototyping approach: – Throwaway prototyping (prototype only used as a demonstration of product requirements) – Evolutionary prototyping (prototype is refined to build the finished system) • Customer resources must be committed to evaluation and refinement of the prototype. • Customer must be capable of making requirements decisions in a timely manner IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 17 Prototyping Methods and Tools • Fourth generation techniques (4GT tools allow software engineer to generate executable code quickly) • Reusable software components (assembling prototype from a set of existing software components) • Formal specification and prototyping environments (can interactively create executable programs from software specification models) IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 18 Specification Principles • Separate functionality from implementation. • Develop a behavioral model that describes functional responses to all system stimuli. • Define the environment in which the system operates and indicate how the collection of agents will interact with it. • Create a cognitive model rather than an implementation model. • Recognize that the specification must be extensible and tolerant of incompleteness. • Establish the content and structure of a specification so that it can be changed easily
  4. 4. 4 IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 19 Specification Representation • Representation format and content should be relevant to the problem. • Information contained within the specification should be nested. • Diagrams and other notational forms should be restricted in number and consistent in use. • Representations should be revisable. IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 20 Specification Review • Conducted by customer and software developer. • Once approved, the specification becomes a contract for software development. • The specification is difficult to test in a meaningful way. • Assessing the impact of specification changes is hard to do IF-ITB/YW/Juli 2005 SE6162 Software Analysis Page 21 Structured Analysis (DeMarco) • Analysis products must be highly maintainable, especially the software requirements specification. • Problems of size must be dealt with using an effective method of partitioning. • Graphics should be used whenever possible. • Differentiate between the logical (essential) and physical (implementation) considerations. • Find something to help with requirements partitioning and document the partitioning before specification. • Devise a way to track and evaluate user interfaces. • Devise tools that describe logic and policy better than narrative text.