Requirements Engineering and Software Architecture Project Description

Transcription

1 Requirements Engineering and Software Architecture Project Description Requirements Engineering Project Description The project is student-driven. There will be external sponsors, users, and others that you need to interact with, but the project team is responsible for the quality of all deliverables, so they must drive the project. The requirements project will be completed in the first part of the semester. The follow up software architecture project will be completed during the remainder of the semester. You will work in teams. You will be provided with a generic application domain. Each team will then select a specific system problem within that domain to represent as stakeholders for another team. Then each team will be assigned to work with two other teams. Teams will collaborate with their developer team in the role of business stakeholder, and with their stakeholder team in the role of developer. Developers will elicit requirements from stakeholders and potentially other users stakeholders recruit. Stakeholders will provide formal and informal review feedback to developers. Work will progress from requirements through architecture activities, building on each other in a progression. Work will be performed in class activities in conjunction with lecture material and outside of class. Each team will produce prescribed requirements and software architecture documents. SWEN440 Software System Requirements and Architecture p

2 Project Activities and Artifacts The project will be incremental. Each increment will produce and review software requirements associated artifacts. The schedule of deliverables is posted on the course schedule and all dropboxes in mycourses have due dates. Project Kickoff (Not graded) The process by which project teams formed will be announced. Organize teams choose a team name, define roles, and plan process logistics. Each team must report their status once per week. A Google Drive document available to the instructor is preferred. Content should be professional, and do not provide personal information such as full names or addresses. The weekly status report needs to contain: A list of what tasks were accomplished for the week, and number of hours contributed by each team member. A list of what tasks are planned for the next week. Any challenges or issues that you need to share. System Selection (50 points) (Stakeholder) The instructor will recommend several target application domains. Once a domain is chosen, do some research, brainstorm, and innovate to identify a system problem within that domain. Better yet, find a collaborative external product champion. You must become knowledgeable enough to adequately represent your system as stakeholders. Review with the instructor to validate the appropriateness and scope of the system. The project scope should be sufficiently broad so as to provide an interesting system problem for software architecture design. Scope might be derived from some combination of external device interfaces, external system interoperability, core computational algorithms, business process user role collaboration, distributed services, and data relationships and operations. There should be an expectation of significant architecture requirements derived from quality attributes such as performance, security, availability, interoperability, and modifiability. So called smart systems in domains such as the home, transportation, manufacturing and supply chain, agriculture, cities, and retail are good candidates. Write up a short introduction overview of your system idea followed by a problem statement and vision statement to be provided to your partner team. The instructor will assign team stakeholder-developer partnerships. NOTE: The following tasks and deliverables are mainly written from the perspective of the developer role. The role responsibility is indicated. In each case you will collaborate and review your work with the stakeholders as directed by the instructor. It is also a good SWEN440 Software System Requirements and Architecture p

3 idea to conduct an internal team review. You will use the Software Requirements template to document requirements. NOTE: An up-to-date status report is due at the time of each deliverable. Business Requirements (100 points) (Developer) Interview your stakeholders to determine business requirements. Document business requirements (5-10), especially those that may have software architecture implications (explain why), the major high level system features, the system scope, and the system boundary represented by a context diagram. User Stories (50 points) (Developer) Document user roles with role profiles. Document user stories (15-20) that correspond to the system features for these user roles. Use Case Model (100 points) (Developer) Model user stories as use cases. Start with a use case diagram that shows all actors and use cases. Write detailed descriptions for 50% of use cases. Include normal workflows and significant alternate/exception workflows. Pick use cases that are of high value, architecturally significant, and/or risky. Derive and document formal well stated functional requirements statements from two detailed use cases. Analysis Model (100 points) (Developer) Model the software for the entire system in one high level UML class or package diagram as a first high level abstraction. Model one use case description as a class diagram followed by an associated interaction (sequence or communications) diagram. The class model should provide sufficient detail so as to be traceable to its use case. At a minimum, details should include class attributes and responsibilities, and message labeling. Proper UML notation is expected. What did you learn about the current validity and state of requirements as a result of performing analysis modeling? Document in the Use Case Document. Non-functional Requirements (100 points) (Developer) Document non-functional requirements. Categories should include quality attributes, significant hardware and software internal and external interfaces, and user interface guidelines. Technology and business dependencies and assumptions should be identified as requirement constraints. Data Dictionary (50 pts) (Developer) Create a data dictionary derived from the use cases you detailed. The dictionary should include the entity name and a description. Document using a table format. Use the data SWEN440 Software System Requirements and Architecture p

4 dictionary to create a conceptual entity-relationship data structure diagram that shows the high level entity relationships. Requirements Inspection (50 points) (Developer) Conduct an inspection review of your software requirements and analysis documents. Your stakeholders will be the reviewers. The reviewers will utilize a checklist. You are responsible for planning and facilitating the meeting. Provide the reviewers with your requirements documents before the inspection with enough time to read it. During the inspection, document defects and other reviewer comments. Summarize your findings. Reflect on what was learned about the requirements and on your requirements engineering process. Note, at this point your requirements document will also be evaluated for good wring practice. SWEN440 Software System Requirements and Architecture p

5 Software Architecture Project Description: As a team you will design a software architecture for the system for which your team specified requirements. You will utilize those requirements to design an architecture for that product. Project Activities and Artifacts The project will be incremental. The first increment will cover product concept and formulate a team plan. Subsequent increments will evolve and review a software requirements specification and associated artifacts. The schedule of deliverables is posted on the course schedule and all dropboxes in mycourses have due dates. The weekly status report started for requirements should be continued for the architecture work. Use the Software Architecture Document template. Most architecture design documents will probably be pages long. Iteration 1 Introduction and Requirements Summary (100 points) Document the introduction, background, requirements, and quality attributes sections of the document. Iteration 2 Big Picture and First View (100 points) Document the architecture overview section of the document. Design rationale is limited to the view being provided. Document your module view design. That should include the view diagram, the associated element catalog, and your view specific design rationale. Review your requirements analysis model as a starting point. It is highly likely the design will need to be revised. Iteration 3 Final Design (100 points) Complete final version of the document, incorporating changes from reviews and feedback of the first two iterations. Include views with associated element catalogs for each of the three categories of structural views: Module Components and Connectors Allocation Specify one architecturally significant interface from the component-connector view. Update system wide design patterns and design tactics decision rationale. Augment with discussion of the pattern and tactics choices made in the context of each view as appropriate. SWEN440 Software System Requirements and Architecture p

6 Review your design. Can the reader understand the traceable relationship mapping of elements across the views? SWEN440 Software System Requirements and Architecture p