Term Project for Systems Engineering Requirements, Design and Trade-Off

Due: 6.30pm, May 16. No extensions!


Problem Statement

The purpose of the term project is to create a frontend system-level representation for an engineering system of your choice. To the extent possible, the system-level representation should be technology independent -- that is, it should simply set the stage for an implementation that could be in software, hardware, or combinations of hardware and software.

I suggest that groups of two students stick to development of a single engineering system.


Things to Do

I realise that this semester we are dealing with a wide variety of project types and, as such, I want to be flexible. Something that works really well for one project may be completely inappropriate for another.

I am particularly interested in seeing things that have not been tried in previous semesters....if you think you have something, let's talk about it and I'll try to help.

Here is a "suggested list" of topics you might like to include in your project:

  1. Project Description.
    Projects should begin with an easy-to-read description of what the project is about. Since these projects will be on the web, I suggest that you make good use of graphics, and use language that a layman can understand.

  2. Goals and Scenarios.
    Briefly summarize the goals and associated scenarios for this problem domain.

  3. Initial Use Case Modeling.
    Identify the actors and system boundary? Develop set of "textual" use cases for this problem domain. For each use case, identify the actors, flow of events for normal and alternative courses of action, and pre- and post-conditions (if they exist). Develop an activity diagram showing the sequence of tasks that are accomplished in the execution of individual scenarios. (It may also be possible to show all of the scenarios on a single activity diagram -- at this point I don't know how big such a diagram would be).

  4. Organize the Use Cases.
    Organize the use cases into a use case diagram. Indicate <<extends>> and <<uses>> relationships between use cases, if they exist. If your project has more than about 10 use cases, think about creating a hierarchy of use case diagrams.

  5. Requirements.
    Develop a set of system and test requirements for this problem domain. Identify the source (i.e., "goal" or "use case") of each requirement (or group of requirements).

  6. Organize Requirements.
    Organize the requirements into layers of development -- each layer should have a well-defined purpose.

  7. Model of System Behavior.
    Create a hierarchy of tasks for "what the system will do." Identify tasks that must be completed in sequence, and any that can be worked on concurrently.

  8. Model(s) of System Structure.
    Identify the key components and subsystems that are needed for the system structure. Organize the components and subsystems into a composition hierarchy diagram and/or component schematic (if you think that is appropriate). Show multiplicities when they exist.

  9. Architecture-Level (logical) Design.
    Map the model of behavior onto the system structure, and show how the various logical scenarios will be handled by the system (i.e., what is the pathway of calculations and messages for each type of computation). I'm envisioning that one or more collaboration, statechart and/or composite-structure diagrams will be appropriate for this task.

    Show how the components will interface with each other, and the external world. Consider:

    Explain how the architecture-level design is constrained by the selection of standards and adoption of technologies.

  10. Use Case/Component Task Interaction Matrix.
    Develop a use case/component task interaction matrix. (I think that the easiest way to do this will be as an html table).

  11. Traceability.
    Develop traceability matrices to show: (1) How use cases trace to groups of requirements, (2) How individual requirements have been taken into account in the system-level design, and (3) Why each system-level component is needed.

  12. Clustering and Modular Design
    Some projects will be amenable to improvement via clustering and modular design with design structure matrices.

    One possibility would be to implement the concepts explained in "Modularity in Design of Products and Systems" by Huang and Kusiak, 1998.

  13. Measures of Effectiveness.
    What are the measures of effectiveness for system assessment at the logical and physical stages of design? How are they evaluated? And what are the difficulties in the evaluation?

  14. Trade-Off Analysis.
    Formulate and, if possible, conduct a trade-off analysis for "design options" versus "measures of effectiveness" at the logical stage of design.

    One parameter of your trade-off anaysis should be estimates of cost. I expect that the remaining parameters will depend on the nature problem you are addressing -- for example, features, performance, reliability ... etc.

    If system cost depends on the choice of technology, then think about conducting the trade-off analysis using [ min, max ] intervals of cost based on technologies that are available.

    Use either CPLEX or the optimization procedures in Excel.

  15. Conclusions and Future Work.
    What have you learned in this project? What was easy? What was hard? Suppose that a team in next years class decides to extend your project -- what should they do next to make the project more complete?

I suggest that you use Visio 2000 for the UML diagrams. If you have questions about web development/html, see the class TA. If you would like to discuss ideas for the latter parts of this assignment, see Mark Austin.


Presentation

Aim for 20-25 minutes (i.e., 12-15 slides only). Focus on the problem statement, and "what you are trying to do that's new..."


What to Hand In and Put Online

Hand in a hardcopy of your final report and presentation (if need be, it can be revised to account for constructive feedback). If your abstract needs updating, then e-mail me the latest version. Also, please e-mail me either doc or pdf version of your work so that I can put it online.


Developed in April 2005 by Mark Austin
Copyright © 2005, Institute for Systems Research, University of Maryland