SET Pool Project
project management
use cases
requirements
structural decomposition
sequence diagram
gaps and conflicts
For this project, our team was tasked with modeling an above-ground pool system and integrating several subsystems and components into a cohesive operating system. Our model’s purpose was to ensure our customers, the homeowners, had the key information they needed to assemble, operate, maintain, and ultimately enjoy their pool.
Our team consisted of 6 people, and I was the project lead. Our project deliverables included use case analysis, requirements list, and structural decomposition as team activities. In pairs, we were to provide a state machine diagram of the assembly process, including pause points that would allow our homeowners to rest during construction, activity flows for the planned operation of the pool and pool maintenance tasks, and a sequence assessment of the message flow necessary for the proper operation of the water filtration and heating system. And our final deliverable was a powerpoint presentation presented in the final class of the semester.
We were provided a video of a conversation between stakeholders, a pool assembly parts list, manuals for the filtration system, pump, skimmer, and an initial pool recirculation system schematic that included information on valves, piping, and fittings. We were allowed to find additional information as we needed, as long as we referenced where our information came from.
We were given a schedule for our project deliverables that included interim reviews and final due dates. As project lead, I was responsible for requesting meetings and interim reviews with our lead Systems Engineer, our professor.
USE CASES
USE CASES
For our Use Case analysis, we determined we needed three diagrams: construction, operation/use, and maintenance. The first one we tackled was the “Operation and Use” Use Case, since we had the information from the stakeholders’ video. All of them were revisiited and refined as we learned more information about our pool system.
-
- Construction
-
- Operation and Use
-
- Maintenance
REQUIREMENTS
Requirements organization quickly became important as we combed through our stakeholder video and manuals. We decided to organize our requirements using packages and figured out how to add a prefix to the requirements in each package. Our categories included Customer Requirements (CR), Health and Safety (HS), Operation and Maintenance (OPM), and Structure (STR).
-
- Customer Requirements Example
-
- Health and Safety Requirements Example
-
- Operation and Maintenance Requirements Example
-
- Structure Requirements Example
We used requirements diagrams to show relationships between requirements and to indicate any outside sources we used for data and analysis.
Requirements definition was an iterative process. As we learned more about the pool system, we could derive and refine additional requirements.
It was through this process, we began to notice gaps and conflicts in our system.
SYSTEM DECOMPOSITION
This was a team deliverable, but I took the lead on System Decomposition. I used the manuals to decompose each system into assemblies and/or individual parts. This was a more detailed decomposition than was required for our project, and we debated removing the parts that weren’t technically required, but we decided that having the part names and numbers ultimately helped us achieve our model’s purpose. Our overall Pool System Structure showed parts by directed composition and references by directed aggregation. The main subsystems, such as the HP Pump, link directly to their respective decomposition diagram within Cameo.
SEQUENCE DIAGRAM – Determine the message flow necessary for proper operation of the water filtration and heating system
For the deliverables where we were required to work in pairs, I worked on our Sequence Diagram that shows the messages between the pump timer, the pump, and the heater system for normal operation of the system. We had five lifelines, including one of our homeowners, the pump timer, the pump, the LCD Controller for the heater, and the heat pump. The initial messages for setting up the timers and the heat pump temperature are synchronous between our user and the respective systems. If the filter timer is true, meaning the pool pump is on, then water flows through the system and acts as an asynchronous message to the heat pump. The heat pump has its own timer that needs to be set for less time than the pump timer. The heat pump checks the timer, checks to make sure there is sufficient water flow, checks the water temperature, and then heats the water as needed. The heat pump then sends an asynchronous message to the user via the LCD Controller. The pump timer would eventually turn off the pump, and water flow through the system would stop.
At one point, we had a much more complicated diagram with alt blocks for the Heat Pump, but we decided it was more detail than needed for our user’s understanding of the sequence and more appropriate for engineers and programmers developing a pool heat pump. We learned that keeping the purpose of our model in mind helps us deliver appropriate diagrams.
SYSTEM GAPS
We did discover several gaps and conflicts. The first thing we noticed was that there was no ladder for our pool. We also discovered that our heat pump was undersized for our pool. We used requirements diagrams to show a gap or conflict and to add notes to indicate where our information came from.
SYSTEM CONFLICTS
Year-round Use Conflict
Our customers wanted to use the pool year-round (CR5.4). They also wanted the water at a “moderate aquatic activity temperature” (CR6), defined in OPM7 as between 78° and 82°F.
We already noted that our heat pump was undersized for our pool size, so it would not heat as effectively or efficiently as one the proper size.
OPM3.8 indicated that a heat pump can’t raise the water temperature more than 30° above air temperature, which makes sense with OPM3.4. It was doubtful our heat pump could heat our water sufficiently for year-round use, assuming North Alabama as the location.
If this were a requirement the homeowners couldn’t compromise on, an alternative could be using a gas heater.
Customer Desired Pool Pump Run Time vs Pool Pump Run Time and Heat Pump Run Time
This was the most impactful conflict we found. Our homeowners desired to run the filter system for a total of 50 minutes per day. HOwever, our research on our heat pump and filter system indicated that the heat pump needed to run a minimum of 2 hours per day and the filter system needed to run a minimum of 5 hours per day. The actual recommendation for the filter in the summer is closer to 10 hours per day. Our recommendation to our customers was to run the filter system for the recommended hours per day, so that their pool was clean and usable.
Gap Recommendation
Lastly, we recommended a solar pool cover. A pool cover was not required for the pool, but it does help meet many of our system requirements for temperature, minimum maintenance, and reasonable cost. (CR6, CR3, CR4). However, it conflicts with CR8: Pool users shall be able to easily enter the pool. The pool users would need to remove the cover every time they want to use the pool and then put it back on when they’re done, and that is kind of a pain. The cover would help optimize the system, but since it was not required for the system, we offered it as a recommendation. The homeowners can decide how they want to compromise between the benefits of a cover and the aggravation of using one.
WHAT I LEARNED
This was our first project using Cameo. It did not always work the way I thought it would, especially when it came to using parts in diagrams. I wish we had thought about coloring coding our requirements, because that would have been useful in viewing the overall table of requirements and in diagrams. When using requirements in diagrams to illustrate gaps and conflicts, I realized how important it is that the wording in requirements be precise. Our system was not that big, and the organization of the model quickly became important in finding things, especially when you had multiple people working on the model. Adding in notes is essential. It was amazing how quickly you forgot where you found something or why you did that or why someone else did that.
Our presentation was too long, and we had too many slides with too much information on them. Our screenshots were often too small to see on the screens in our classroom. It’s all part of learning, and we know more about presenting next time.
Overall, it was a fun project. We worked well together as a team and communicated information with each other so that everyone had a good understanding of the system we were modeling. Even though we exceeded our presentation time, our professor gave us high praise.
