week4-3 - Requirements Engineering Requirements Analysis...

Info iconThis preview shows pages 1–7. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Requirements Engineering: Requirements Analysis Michael Gr¨uninger Semantic Technologies Lab University of Toronto September 27, 2010 Gr¨uninger (MIE350) Requirements Engineering September 27, 2010 1 / 21 Challenge The requirements that have been gathered from the users typically have the following problems: Ambiguity Redundancy Inconsistency Incompleteness Unverifiable Lack of traceability Over-specification Gr¨uninger (MIE350) Requirements Engineering September 27, 2010 2 / 21 Requirements Classification Take the unstructured collection of requirements, group related sets of requirements, and organize them into coherent clusters. How are requirements related to each other? Are they all at the same level of abstraction, or are some refinements of others? Gr¨uninger (MIE350) Requirements Engineering September 27, 2010 3 / 21 Requirements Validation We must ensure that all parties (users and developers) agree on the requirements to ensure that the correct requirements are stated. No hidden assumptions! Techniques for validation: I use cases I prototypes Verification will ensure that the requirements are stated correctly. Gr¨uninger (MIE350) Requirements Engineering September 27, 2010 4 / 21 Ambiguity Can the statement of a requirement be interpreted differently by people with different backgrounds or in different contexts? What are possible interpretations of a statement? terminology clash – using different names for the same concept designation clash – using the same name for different concepts Prototypes can be used to illustrate alternative possible interpretations of an ambiguous requirement. Gr¨uninger (MIE350) Requirements Engineering September 27, 2010 5 / 21 Redundancy When collecting requirements from multiple stakeholders, similar requirements may be stated in different ways....
View Full Document

This note was uploaded on 09/20/2011 for the course MIE 350 taught by Professor M.gruninger during the Fall '10 term at University of Toronto.

Page1 / 21

week4-3 - Requirements Engineering Requirements Analysis...

This preview shows document pages 1 - 7. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online