Requirements Analysis, Systems Development: LBG

Systems Development: Requirements, Design, Implementation, Testing

Requirements Analysis

Requirements Specification to System Specification: There is a Progression

So far we have performed the following requirements related tasks:

Assessed the needs, murmurs, and wants of our customers.
Translated those into engineering requirements.

Can we start our design phase yet? Almost but not quite. We need to first make sure that our requirements agree with one another. Then we need to partition these requirements into subsystems: some requirements will be met by a database, for example, while others may be met by a web page.

We also must communicate clearly to the customer exactly what transactions we are going to build. We must document every interaction an external entity, be it a person or another system, has with the system under development. This documentation is at a high level and using descriptive language, something like a story. None the less, without fully defining the system capabilities in natural language, we run the risk of something critical to the system design–or worse yet, the customer.

Process Activities

In our requirements specification sub-phase, we mentioned the importance of merely translating as much of the customer's original ideas as possible. We specifically deferred finding conflicts among the requirements until a later time. Well, now is that time!

We will use the outputs of our requirements specification assignment as inputs to this requirements analysis assignment. We then perform the following tasks:

Resolve conflicts among requirements: Review our system specification and look for requirements that are in conflict with one another. When a conflict is found, modify one or the other requirement, or perhaps both, to eliminate the conflict.
Perform top-level subsystem decomposition: Some requirements will have a natural affinity for each other and should be grouped together. We do this by grouping requirements supporting the same top-level function into a subsystem.
Define subsystem inputs, activities, and outputs: Since we collected requirements into subsystems, there must be some communication among subsystems. For example the output of one subsystem.
Develop top-level use cases: Model each and every transaction a customer can have with the system as a use case. Perform this at the system level only.

Exercise

The final requirements step, the third sub phase, is to enhance our existing specification with the additional work performed in this unit. The final document will be a specification ready for the design phase. Pay particular attention to the assignment requirements. Do the work requested well, but do not perform extra, needless work.

For demonstration purposes, here is a specification with a sample input-process-output diagram and schedule:

English

Study Guides

Use the following study guides to focus concepts from the readings:

Lecture Slides

Here are copies of the lecture slides presented during class:

Readings

As before, each of the listed links will open in a new browser window:

Concept	Notes	Links
Definitions	Here are some basic articles about requirements analysis and object oriented analysis. All of the activities we follow in this unit derive from one of these two disciplines.	Requirements analysis: A Wikipedia article. Object Oriented Analysis: A Wikipedia article. Requirements Engineering Key Practices: Karl E. Wiegers, Process Impact. Read the sections entitled Focus on User Tasks, Define Quality Attributes, and Prioritize Requirements.
Conflict Resolution	Unfortunately most of the formal computer science literature for requirement conflict resolution is way beyond the scope of this course. Here are two articles that might be a source for ideas on the topic:	An Ethical Theory for the Advancement of Professionalism in Software Engineering: Nicole Radziwill, National Radio Astronomy Observatory. This paper goes beyond the disciplines of engineering, math, and science to answer questions about how to resolve technical conflicts. Goal-Oriented Requirements Engineering–A Guided Tour: Axel van Lamsweerde, Département d'Ingénierie Informatique, Université catholique de Louvain. This paper, following goal methods, is a balance between the above and below methods. Classifying Requirement Conflicts for Multi-Stakeholder Distributed Systems: Frank Marschall, Maurice Schoenmakers, Technische Universität München. This paper delves more into the engineering side of the equation.
Input-Process-Output (IPO) Diagrams	In addition to the IPO diagram in the sample specification above, here is an additional example and some explanatory text:	Key Input and Output Diagram: AESO System Projects. An IPO diagram example from project management. Problem Analysis and Program Design: Using Subsystems and Strategies, Robert F. Zant, Illinois State University. Section 2 covers single and multi-level IPO diagrams. Note for this unit only a single level decomposition is required.
Use Cases	Originally developed in 1986 by Ivar Jacobson, use cases are the cornerstone of object oriented analysis. They have grown in popularity and are now used outside of software engineering circles.	Use case: A Wikipedia article. Background, definition, and reasoning behind use cases. Use Cases: A short, brief, to-the-point treatise on use cases courtesy of the US Department of Health and Human Services. Functional Requirements and Use Cases: Ruth Malan and Dana Bredemeyer, Bredemeyer Consulting. Pages 2 and 3 compare and contrast these two requirements engineering tools. Use Cases – An Introduction: Jason Gorman, Parlez UML. An elementary overview of use cases with many diagrams and examples.
Unified Modeling Language Tutorial	UML is a formal diagram notation. Here is a tutorial on how the notation works. For this unit, we are only concerned with use cases.	Types of UML Diagrams: From The Kennesaw State University UML Tutorial. Braun, Sivils, Shapiro, Versteegh.

Copyright ©2006-2009, Jason Paul Kazarian. All Rights Reserved. License for reproduction, derivative works, internal commercial, and external non-commercial use granted to GITC faculty, staff, and students.