INFO 627Lecture #81 Requirements Engineering and Management INFO 627 Building the Right System Glenn Booker

INFO 627Lecture #82 Overview  So far we’ve been able to define equirements, specify them clearly, and ensure they have good quality  Now we need to ensure that the system we create really does implement the requirements we’ve defined

INFO 627Lecture #83 Key Implementation Concepts  Need to confirm that the stated requirements really are being implemented (verification)  Need to make sure development keeps conforming to customer needs (validation)  Deal with change during development

INFO 627Lecture #84 Verification versus Validation System Customer Needs Defined Requirements VerificationValidation

INFO 627Lecture #85 Verification Should Prove Use cases and requirements which are derived from features really do support the intended features Use cases are reflected in the design The design supports both functional and nonfunctional aspects of the system’s behavior Code conforms to the design Testing covers all use cases and requirements

INFO 627Lecture #86 Verification  Verification is often done through traceability, which we’ll discuss shortly  Key concept for verification is that every activity looks back to the previous step and makes sure nothing got left behind, or forgotten  Other verification methods include inspection and review

INFO 627Lecture #87 Verification Cost  We need to balance the amount of time spent doing verification, so we don’t overdo it, or miss something important  Will show next week how to use risk to guide the right level of verification  Verification applies to all phases of the life cycle, but is most critical early on

INFO 627Lecture #88 Verification  Testing is also mostly a verification activity  Verification is done by many members of the project team – it isn’t just a QA job  A process for verification needs to built into the life cycle to ensure it is consistently performed

INFO 627Lecture #89 Validation  Validation is the act of proving that the system you are creating meets the needs of the customer (sponsor, users, etc.)  Can map user needs to product features, another form of traceability  Validation is often done at major milestones End of life cycle phases, end of iterations, etc.

INFO 627Lecture #810 Validation  Need to demonstrate the product in the customer’s environment to assess the subjective “are they happy with it” criterion  Main reason for validation is to ensure the customer needs didn’t drift from when the requirements were captured

INFO 627Lecture #811 Managing Change  Finally, we’ll discuss how to manage changes to requirements during development – since we can guarantee they will change  This will also be covered next week

INFO 627Lecture #812 Implementing Requirements  While software development has been able to accomplish many spiffy things, getting from requirements to implementation is not a simple matter  Sometimes it is hard to prove that a particular piece of code fulfills a requirement

INFO 627Lecture #813 Implementing Requirements  Implementing requirements is sometimes straightforward  Easily implemented requirements often written with detail to guide the developer, and may invoke familiar concepts Task progress status Role or organization-based security modeling Citing specific math concepts or algorithms

INFO 627Lecture #814 Tough Requirements  The toughest requirements to implement are Too vague, so there’s little idea what level of complexity or control is desired, e.g. “allow editing based on security defined by the system administrator” Non-functional requirements, which are often process-oriented, but the code itself is a logical structure

INFO 627Lecture #815 Tough Requirements  Text calls the argument between process and logic ‘orthogonality’ (which normally refers to right angles)  Tough requirements can be like left-brain versus right-brain thinking Artistic & creative thought vs. logical & linear How do you give driving directions?

INFO 627Lecture #816 Tough Requirements  Tough requirements can also focus on scale issues such as system-level requirements Can be addressed by the systems engineering approach we discussed earlier  Requirements which are distributed throughout the system are also often difficult (e.g. use of interface standards)

INFO 627Lecture #817 Tools for Tough Requirements  Key ways to address tough requirements are through using proven design patterns or metaphors Bringing Design to Software, by Terry Winograd et al, ISBN Design Patterns, Erich Gamma et al, ISBN And WWISA recommendationsWWISA recommendations

INFO 627Lecture #818 OO Helps Too  Use of object-oriented methods can help resolve some orthogonality issues, by combining data structure with process- oriented methods  Beware that direct mapping of functions to objects can result in non-OO structures

INFO 627Lecture #819 Use Cases  Defining use cases can help see the big picture of the system’s role, and keep from focusing too closely on a particular function  So while the orthogonality problem won’t go away, these approaches can help overcome it

INFO 627Lecture #820 System Modeling  Software systems can involve thousands of modules and millions of lines of code  To help break down their complexity we need a good modeling tool  We need to hide the details and understand the high level

INFO 627Lecture #821 Modeling Analogies  Our need to understand software at a high level is similar to other fields’ needs In astronomy, cosmology tries to understand the structure and evolution of the universe In physics, various unified field theories try to relate all of the electromagnetic forces  In comparison, our job is easy!

INFO 627Lecture #822 System Modeling  We use system architecture to understand What the system does How it works The role of each part of the system  And be able to support Extension or expansion of the system Reuse of the system

INFO 627Lecture #823 The 4+1 View of Architecture  The 4+1 architecture view by Phillipe Kruchten can help capture the architecture by looking at different aspects of the system Kruchten  Like a house architect might have different drawings to capture the structure, wiring, plumbing, external appearance, etc. Keep in mind that the Kruchten paper was written before UML.

INFO 627Lecture #824 The 4+1 View  The 4+1 views are Logical view, such as the subsystems and classes within the system Implementation or development view, which is the structure of the code in its environment Process view, to capture timing and coordination issues Deployment or physical view, the hardware

INFO 627Lecture #825 The 4+1 View  The +1 part are scenarios or use cases, which tie all of the parts together Logical Process Implementation Deployment Use Cases

INFO 627Lecture #826 Logical View  The logical view is the structure of the data and objects needed to support system functionality  Appears as a class diagram or entity-relationship diagram (ERD) See my UML summary for more information on the diagrams.UML summary

INFO 627Lecture #827 Implementation View  The structure of the code is often shown by grouping modules into bigger pieces, or different layers (think OSI reference model)OSI reference model  From small to large, typical names are package, component, and subsystem  Hence it is no surprise that package, component, and subsystem diagrams may show this view

INFO 627Lecture #828 Process View  The process view mostly helps understand non-functional characteristics, based on the process flows  Timing, synchronization, concurrency, and fault tolerance are all addressed by the process view  Sequence, collaboration, statechart, and/or activity diagrams may show this view

INFO 627Lecture #829 Deployment View  The deployment view focuses on how the system is physically located on computer systems  Hence this helps focus on installation and networking issues  Shown with a deployment diagram

INFO 627Lecture #830 Use Cases Tie It All Together  As the four main views are being developed, the use cases or scenarios can help ensure the models are all consistent with each other  Trace how each scenario appears from each view’s perspective  This approach is also used by the Rational Unified Process

INFO 627Lecture #831 Collaborations  Collaborations are conceptual classes which allow a direct link between a use case and the classes which implement it (p. 328)  A collaboration may appear in a class diagram, but does not reflect an actual class, it represents a set of classes and behaviors  See the UML specification for more infoUML specification

INFO 627Lecture #832 Modeling Summary  Hence the best way to get from requirements to code is to define a set of inter-related models of the system, capturing its logical, implementation, process, and deployment characteristics, while ensuring that the use cases can be fulfilled using those models

INFO 627Lecture #833 Traceability  Traceability is a key technique for verification of requirements  Tracing can be done from the features in the Vision document, all the way down to testing  Tracing can’t be automated, but tools can help make it easier

INFO 627Lecture #834 Traceability  Need to establish traceability so that when requirements change, we can tell what was affected by the change  Traceability shows the connection between two things, and hence can show why something exists in the system  One-to-many connects are common One feature may trace to many requirements

INFO 627Lecture #835 Traceability  In defining traceability, we could identify where something traces to, or from “From” is easier to keep track of in most cases, e.g. “Feature B traced from Need A”; why? Need A Feature B Req’t C

INFO 627Lecture #836 Explicit vs. Implicit Traces  An explicit trace between two things means that the connection is not obvious, and must have been determined by the project team  An implicit trace is implied, such as parent-child connections Feature X traces to requirements X.1, X.2, and X.3 Don’t need to state implicit traces

INFO 627Lecture #837 Other Things to Trace  Might want to include other ideas in connection with tracing requirements Assumptions and rationale for decisions Action items or TBD lists Requested new features Glossary and terminology Bibliographic or other references  Just don’t go overboard!

INFO 627Lecture #838 Traceability Tools  Major CASE tools can often help trace relationships Rational (IBM), Aonix, and others  They can’t tell what the relationships are, but can help maintain the connections and make it easier to document them

INFO 627Lecture #839 What Can Be Traced? NeedsFeaturesRequirements Use Cases Design Models Test Cases Code Releases Actors (not a complete list!)

INFO 627Lecture #840 How To Show Traceability  Any kind of traceability can be shown using a table or matrix Columns representing a low level thing (e.g. requirements or use cases) Rows represent a high level thing (e.g. features)  The presence of an “X” or check mark means that the column (requirement) helps fulfill whatever is in that row (feature)

INFO 627Lecture #841 Verification Using Traceability  Every column should have at least one “X” That requirement doesn’t correspond to a known feature (excess verification); maybe a superfluous requirement?  Every row should have at least one “X” That feature never got mapped to a requirement (omitted verification); oops!  Many “X”s is usually acceptable

INFO 627Lecture #842 Maintaining Traceability  Traceability can be shown several ways, such as the tree and list formats  Automated tools are very helpful in generating these views easily  If an automated tool isn’t available, a relational database may be needed for projects of any significant size

INFO 627Lecture #843 Correct and Complete  Just checking for “X”s in each row and column isn’t enough  That won’t prove whether each connection is correct and complete  Some sort of review is often needed to obtain agreement on those issues  Reconsider links when project scope or environment changes