Conclusion of Medical Device Management
Conclusion of Medical Device Management
Conclusion
Over the course of completing the exercises summarized in this document (and as new techniques were explored), we realized that the requirements development process involves continually finding relations between requirements, and drilling down to a greater level of detail at each step. Our personalities were evaluated to be fairly similar during the personality exercise (we were all categorized as Extroverted, Sensing, Thinking and Judging), but we found that we worked very well as a group. We had expected to have some conflicts between group members due to the Judging aspects, but instead we found that we progressed very easily through the activities. This was likely due to our adopted organization and delegation of tasks, as well as our awareness of our personality issues. Based on our experiences, we formulated the following list of what we found to be the best aspects of each of the techniques covered: The Personality Exercise made us aware of possible faults ahead of time and allowed us to prepare for any related obstacles having a good facilitator/leader is important when many of the group members are of the Extroverted type allocating tasks based on personality type allows people with appropriate skills to put those skills to use
Interviewing this was a very easy and systematic method for quickly gathering the top level of requirements. These can then by used later as a basis of gathering more detail
Reperatory Grids this method helped us to strictly define elements within our system (such as hospitals, ward and nurses) and their functions
Concept Maps useful for finding faults in logic, or missing items such as missing requirements in the SRS
valuable for their ability to capture and communicate ideas accurately and easily
Organizing and Prioritizing Requirements given time limits on the implementation of a project, this method ensures that the most important requirements will be implemented
Software Requirements Specification the best specification results from a team effort rather than one individual helped us to find ambiguous requirements
Software Life Cycle various part of each of the techniques should be combined and applied to fit the situation
The Software Requirements process, as a whole, is an iterative process. Despite that the exercises were conducted in a controlled, academic environment, the supplemental reading and material describe many practical situations and solutions in practice. Thus, the material covered forms a good basis for application in the workplace.