11CMSC735Discussion of the UMD Assignment2Results from Post Study Questionnaire3Difficult aspects to understand from lectures• “A lot of gray area which allowed us to think about things more on our own” (good or bad?)• “I would have liked to see some basis for evaluating completeness of requirements”• “Difficulty in understanding how we distinguish functional and non-functional requirements”• “Some simple examples/case studies would have made it easier to understand”• “It would be helpful if we had been shown a small but complete model” (using UMD?)4Comfort with the e-bookstore domain• Very comfortable (3); A great problem to work on (1)• “A good problem (everyone is familiar at least from user’s point of view)” (1)• “Too broad to be able to cover all aspects” (e.g., no time to specify failures for reaction services)• “Only a short description of the requirements which was ambiguous”But also…5How the UMD approach helped elicitation• “It helped to have a standard format in which requirements are written and to emphasize issues that I would have known to include in the requirements (e.g., response time)”• “The model helped viewing the problem in a specific way that made various aspects of dependability described in a unified manner” (bad or good? Do we loose expressiveness?)• “The UMD approach helped a lot in expressing the dependability requirements (once I have got the hang of it)”• “UMD approach helped by organizing our though process and codifying failure information in a way that can be analyzed later”6How the UMD approach hindered elicitation• “I had trouble expressing functionality requirements using the given fields”• “The scope and the difference between mitigation and guard services was the hardest part for me to understand”• “The hardest part was to define the failure types”• “There were some ambiguities about the terminology (overcome after some experience)”• “Coming up with failure measure seemed hard. I would have preferred using an ordinal scale”27How the UMD Tool helped elicitation• “Since everything was so structured, it was easy to break down stakeholders’ demands into their parts”• “It was easy to enter and organize data”• “The tool was an exact representation of the model, hence easy to understand”• “Helped us codifying and organizing the dependability requirements”8How the UMD Tool hindered elicitation•“printing took forever” – “printing time consuming”• “It was hard to look at one of more requirement at a time, navigate between requirements and scopes”• “Hardest aspects were probably ability to maneuver across pages”• “It can’t sort issue list easily”• “Another pain was that all the scopes had to be defined earlier on to get them as selections”• “Complicated requirements could only be achieved through separating requirements” (good or bad?)• “Hardest was expressing failure requirements (tend to make them sound like requirements rather than failures)” (?)9How to make the assignment easier• “I do not think the assignment was hard (it was the easiest one)”• “An on-line help would be nice, with a step by step guide to creating a model”• “A more sophisticated tool” – “Tool needs a major rework”Everybody like the tool!!! • “One lecture with on-line access”• “A practical example before the assignment”• “More training, more explanation of the expectations of the project and basis for evaluation”• “A detailed requirements document”• “Explain roles of stakeholders more clearly”10Difficulties with Negotiation• “The difficulty was understanding what the other stakeholders were talking about and agreeing on the words and terms”• “Agree on system reactions took some time”• “Narrowing down our scope list and unifying everyone issues”• Time consuming• “Failures were very similar, only the degree was different, so wewent with the most lenient criteria”• “Identify conflicting requirements”11How UMD approach helped Negotiation • “UMD approach helped in combining requirements, since everyone’s requirements could be easily understood by everyone else”• “Provide a standard format”• “The model helped us very well in combining requirements, because we already had models in the same format (it would have been more difficult to start from scratch and reach same completeness)”• “The greatest strength of UMD is be able to merge requirements. We had no trouble identifying potential conflicts and resolving them”• “Most difficult part was identifying the best measure (we had no information on the measure and it was difficult to negotiate)”12How UMD approach hindered Negotiation• “Most difficult part was probably adjusting the failure criteria (measure?) and eliminating trivial requirements”Few points… this is good313How UMD Tool helped Negotiation• “The tool helped because let us know exactly what we were talking about”• “The tool helped to unify”Few points… this not too good14How UMD Tool hindered Negotiation• “Most difficult part was scrolling across the page to reach the different aspects (guard services, measure, stc.)”• “Another difficulty is the inability to see the summarized version with all field (easier to proof/read)”• “Difficult to compare requirements within and between models (cannot copy requirements from one model to another)”• “No way to transfer data from one model to another (we had to re-enter a good part of data by hand)”•“There is not even a merge option in the tool!!!”•“Tool was unhelpful at this stage”Many points… this not too good!!15Particular aspects of the inter-group Negotiation• “Not all members could attend all meetings (part of the work doneby smaller groups)”• “Different individuals had different interpretations of what various fields in the model meant. This became even worse given that manager and customer groups arrived at different consensus”• “Agreement on failure criteria (failure type, measure?) was the most difficult aspects. Managers designed a very lenient system which was not satisfactory for the customers; managers did not want to design anything that would have add to their expenses; customers had to low their expectations; few managers requirements were update to increase