Se6162 analysis concept and principles
0 likes393 views
This document discusses software analysis concepts including requirement analysis, elicitation, and specification. It covers key principles such as understanding user needs, developing prototypes, and creating hierarchical models. Requirement elicitation techniques include interviews, meetings, use cases and scenarios. Analysis models the information domain, functions, and system behavior through data, functional and behavioral models. The specification captures requirements but separates functionality from implementation through a behavioral model.
![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](https://image.slidesharecdn.com/se6162analysisconceptandprinciples-101112015317-phpapp02/85/Se6162-analysis-concept-and-principles-2-320.jpg)
Se6162 analysis concept and principles
- 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 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 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 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.