Problem Analysis and Solution Requirements (PASR)

Total Page:16

File Type:pdf, Size:1020Kb

Problem Analysis and Solution Requirements (PASR)

Problem Analysis and Solution Requirements (PASR) Answers to the questions on the sheets 27-01-2008 By Floor de Jong

Course period: 2nd quartile of year 2007/2008 Teacher: Prof. Roel Wieringa Assistents: Virginia nunes leal Franqueira and Eelco Eerenberg.

Chapter 1 – Introduction 1. (Chaos) Software requirements tend to change constantly. What is the recommendation of Chaos to deal with this? “The three major reasons that a project will succeed are user involvement, executive management support, and a clear statement of requirements.” (Chaos report 1994) Success factors (Chaos report 2000): 1. Executive support 2. User involvement 3. Experienced project manager 4. Clear business objectives 5. Minimized scope 6. Standard software infrastructure 7. Firm basic requirements 8. Formal methodology 9. Reliable Estimates 10. Other  Especially number 7 deals with changing software requirements. “By creating a minimal, obtainable base level of requirements and then developing those features, the effect of change will be reduced. Changing requirements is as certain as death and taxes. Delivering minimal features allows users and executive supporters to see results quickly. As a result, an added benefit is that project managers are better prepared to articulate the needs and priorities of the next phase of the project.” (Chaos report 2000)

2. (Chaos) Which of the 10 factors for project success improve the match between software solution and business needs? Why? Number 4; Clear business objectives. In the report of 1994 this was called “Clear Statement of Requirements” and was on the third spot with 15 points. Requirements or the business objectives link the software solution to the needs of the business.

3. (Chaos) The Chaos 10 indicate that requirements engineering is expectation management. Why? Requirements engineering is managing the requirements, or whishes and needs, of the stakeholders. According to the Chaos report (2000) these requirements will definitely change (see question 1), so they have to be managed. Managing the requirements is the same as managing the expectations of stakeholders because requirements arise from and reflect their expectations. Furthermore Figure 7 shows what Wieringa says in a later chapter (chapter 5). Figure 1 - RE is expectation management (Wieringa, chapter 5, slide 14)

4. (Davis) Why are hidden errors the most expensive to repair? Errors that are hidden are detected later in the Life Cycle Stage. According to Davis (1993) the relative costs of repair increase 200 times from 0.1-0.2 in the requirements stage to 20 in the maintenance stage (hypothesis 1). He states that “the additional cost may be due to the need not only to correct the original offending error but subsequent investments in the error that have been made during later stages” (possibility b, page 26).

Chapter 2 – Problems and Solutions 1. Describe an organizational problem and a software solution. According to Wieringa (slides chapter 2) “a problem is a difference between what is experienced and what is desired” and “a solution is a system that provides desired services”. A system in this context is not a software system but a ‘system’ in the most abstract sense. The definition Wieringa gives is that a system is a “set of elements with relationships among them that have emergent properties”.  An example of an organizational problem is “the helpdesk is not functioning well” (Wieringa, slides chapter 2) and a software solution (possibly, but not necessarily to this problem) is ‘a new interface to a software system’.

2. Describe a software problem and an organizational solution. The problem will be something like ‘the financial system is too complex to work with for a non-expert’ and a proposed organizational solution is ‘to hire an expert to do the financial tasks’.

3. What is an implementation for a software engineer is not an implementation for the business manager. Describe and explain the difference. According to Wieringa (slides chapter 2): “Whether something is a specification or an implementation depends on who you talk to”. The implementation of a business manager is the specification of the software engineer, because it sets the boundaries within which he has do define his implementation. E.g.: A business manager defines an implementation as follows: “In the business process the helpdesk finds the contact details of a customer by entering his name or customer number in the system”. This is a specification to the software engineer who then has to implement this in code or class diagrams, which then are in turn the specification for a programmer.

4. Explain the relationship between each problem and its problem owner on the slide about problem relativity (slide 10). Figure 2 – Problem relativity (Wieringa, chapter 2, slide 10) The problem a person has depends on his knowledge and interests. Somebody without detailed IT knowledge (in this case the CIO) has in this case a problem on a higher level because he does not understand it. Furthermore he does not want to re-invent the wheel and has interests in reducing the risk. Therefore the solution of the CIO is to ask CISCO. The infrastructure manager has detailed knowledge on infrastructure and wants to optimize the infrastructure and therefore sees the problem on that level. The procurement manager sees the problem of buying appropriate software infrastructure and does not know how to solve this by lack of IT knowledge. Therefore he proposes to outsource the problem. The software engineer is already looking for a proper way to manage the project because he assumes that they are going to develop it in-house. This is because he has enough IT knowledge to define the impact of such a situation and he has already decided that it is possible to do it in-house. The marketing manager has knowledge about what the customer wants and needs and therefore sees a marketing problem. He is interested in offering the best solution to his customers. The CFO is interested in the costs and has financial knowledge through which he has defined that this problem can help reduce the sunk costs. Therefore he sees this as a financial problem.

Chapter 3 – Problem-Solving 1. Explain why requirements are designed. According to Wieringa (slides chapter 3): “to design is to specify a solution to a problem”. He also states that “requirements are desired solution properties”. If requirements are properties of a solution, they specify this solution and therefore are designed. “A requirement for X is a desired property of X” (Wieringa, slides chapter 3) and therefore describe the solution. Designing is ‘saying what you want to do” (see Figure 3). Requirements say what you want to do to reach the solution and therefore are designed.

Figure 3 - Designing and implementing (Wieringa, chapter 3, slide 4)

2. “A software design results in software specifications.” Explain. This is inherent to the definition of design. As said in question 1 “to design is to specify a solution to a problem” and therefore leads to a specification by definition. In the case of software design, the requirements specify what the software has to do (the properties of the software).

3. “Software requirements are what a SW system must do, SW design is how it must do it.” Explain what is wrong with this statement. Software design are the software requirements. Since the software design specifies the software it defines what it must do. How this is done is not part of the design but of the implementation, where you do what you said. Of course it may be a new, nested, problem how to implement the specification and therefore this can be designed which results in more detailed specifications. However, a design will always deliver the specification of a solution, which may be a solution ‘how to do it’, but always includes ‘what it must do’.

4. Engineering design contains a feed forward loop. Explain this. According to Wieringa “the engineering design cycle consists of problem investigation, solution design, solution validation”. As one can see in Figure 4 each of these activities is connected to the other two in both directions. So there is a feed forward loop, which means that influences are measured and on this base outcomes can be predicted. An example is that on basis of the requirements identified during the problem investigation, one can predict the solution specification identified during the solution design and thereby predict the solution validation. However, directly from the requirements it is also possible to predict the solution validation.

Figure 4 - Engineering cycle (Wieringa, chapter 3, slide 13)

Note: Dictionary.com1 says that feed-forward is “A multi-layer perceptron network in which the outputs from all neurons (see McCulloch-Pitts) go to following but not preceding layers, so there are no feedback loops”. In that case there are no feed forward loops because the cycle definitely contains feedback loops that make feed forward loops impossible.

5. Classify the examples of slide 15 according to the classes on slide 14. 1. Solution driven (research). Because the solution is clear (the quick scan), but the problem it can solve is not. Research because there is no practice linked to the assignment. 2. Solution elaboration. Not improvement-driven because there does not exist a solution yet. 3. Solution elaboration. Not improvement-driven because there does not exist a solution yet. 4. Problem-driven. 5. Solution elaboration. Not improvement-driven because there does not exist a solution yet. 6. Solution elaboration.. The problem is given (to buy a WFMS) as well as a solution direction (a method).

1 Feed-forward. Dictionary.com. The Free On-line Dictionary of Computing. Denis Howe. http://dictionary.reference.com/browse/Feed-forward (accessed: January 27, 2008). 7. Problem-driven. Same as previous, but the solution direction is not given. 8. Problem-driven. Solution is unclear, the problem is given. 9. Improvement-driven. 10. Solution elaboration. 11. Improvement-driven. 12. Solution-driven (practice). 13. Solution-driven (practice).

Figure 5 - Examples (Wieringa, chapter 3, slide Figure 6 - Engineering drivers (Wieringa, 15) chapter 3, slide 14)

Chapter 4 – Problem Identification 1. Mention a few gaps between your experience and desire that are no problems - I do not earn €10.000 a day. - I did not finish this course yet. - It rains outside.

2. Mention gaps between your experience and desire that are difficult to close but you don’t want to close - The sleeve of my sweater falls off so I have to stitch it (but I don’t want to). - I’m in dept with the IBG which I have to pay (but I don’t want to). - I had a fight with my housemate and I have to make it up with her (but I don’t want to).

3. Mention gaps between your experience and desire that you want to close and are easy to close. - I did not finish this course yet (so I prepare to get a good grade for the exam). - I am hungry (so I eat). - I want to speak to my boyfriend (so I call him).

4. (Bossworth) Your customer has a gap that can be closed but he is not aware of. What should you do? Give him hope. According to Bossworth “your challenge as a seller is to get an issue that your product or service addresses into the buyer’s foreground brain” and “the only motivation we have for dealing with a pain in our foreground is hope – hope for a solution”. This means first my customer has to admit his ‘pain’, which I can reach by giving him hope (e.g. through a reference story). Secondly, I have to begin to create a vision of a solution for my customer. I can do this by following the 9-Block Vision Processing Model, especially the Vision Creation Prompter depicted in Table 1 because my customer does not have a vision yet. Table 1 - Vision Creation Prompter (Bossworth, 1995) Diagnose reasons Explore impact Visualize capabilities Open 1 4 7 Tell me about it, Besides yourself, What is going to take what is causing you who else is impacted for you to solve this to have this (repeat by this(repeat pain), (repeat pain)? pain)? and how are they Could I try a few impacted? ideas on you? Control 2 5 8 Is it because? Is this (pain) also What if there were a causing…? If so, way for you/your wouldn’t (title) be people to …, would concerned? that help? What if you were also able to…? Confirm 3 6 9 So, the reasons for From what I’ve just From what I just your (repeat pain) heard (repeat the heard, if you had the are…? who and how), this ability to … (repeat isn’t just your capabilities) could problem, but a ___ YOU solve (repeat problem? pain)?

5. Your customer wants to solve a gap that cannot be closed. What should you do? According to Wieringa (slides chapter 4) “if gap is impossible to close, and you would like to close it: just forget about it”.

6. (Bossworth) explain the relationship between the 9-block vision processing model of Bossworth and the problem-solving tasks of slide 2. The problem solving tasks are shown in Figure 7. Hereby we can relate the problem identification to the fact that the customer has recognized his pain. The problem definition is step 1 to 3, the problem structuring steps 4 to 6 and the problem diagnosis is the same as steps 7, 8 and 9. The other parts of the engineering cycle are not mentioned in the 9-block vision processing model of Bossworth.

Figure 7 - The problem-solving tasks (Wieringa, chapter 4, slide 2)

Chapter 5 – Problem definition 1. Explain why goal-oriented RE may bring you beyond your problem solving charter. According to Wieringa (slides chapter 5) “the problem solving charter determines the boundary between your problem and what you cannot change”. The goal-oriented RE focuses on the desired outcome, on what the customer really wants and thereby increases our solution space (Wieringa, slides chapter 5). Because we know better what the desired outcome is, we may consider other, new, solutions which means that the boundaries of our charter will move and the charter will become broader.

2. What happens if your environment assumptions turn out to be false? “An assumption is a proposition about the environment that you assume to be true”, which means that you will be wrong when it turns out to be false. Depending on how much the solution depends on the assumption you may have to redesign a part or may be the whole solution.

3. What is the difference between an assumption and a requirement? According to Wieringa: 1. “An assumption is a proposition about the environment that you assume to be true” 2. “A requirement of X is a desired property of X” and “A requirements specification is a description of what the solution will do to solve the problem” So an assumption is a description of the environment and a requirement is about the solution. They both reflect expectations, but in an assumption it are the expectations of the designer and in a requirement it are the expectations of stakeholders.

4. Rewrite problems P1 - P6 of slide 3 in one of the forms of slide 152. P1 Solution-driven (practice): Find out whether can solve of under . P2 Solution elaboration: Elaborate on of of under . P3 Problem-driven: Design of under . P4 Solution elaboration: Elaborate on of of under . P5 Solution elaboration: Elaborate on of of under . P6 Solution elaboration: Elaborate on of of under .

2 The original question mentioned slide 15, but 16 seemed more logical to me so I assume that it was a type error. Figure 8 - Examples of project formulations Figure 9 – Problem definitions (Wieringa, (Wieringa, chapter 5, slide 3) chapter 5, slide 16)

Chapter 6 – Stakeholder Analysis 1. Answer the question on slide 6: Who are the likely stakeholders, and what do you think are their desires, in problems P1 – P6? According to Wieringa stakeholders are “persons who experience the gap (problem owners), or who are impacted by reducing it”.

P1 Which set of methods and techniques from our “methods cookbook’’ are relevant for realizing IT-enabled change? Likely stakeholders: . The persons working with the cookbook, who want to keep it as short and comprehensible as possible. . The persons who wrote the cookbook, who want to keep it as it is, or maybe even expand it. . The management, who want to realize IT-enabled change, decided to use the cookbook and therefore need to make it as accessible as possible.

P2 Select and implement a logistic financial package with an eye to future IT developments Likely stakeholders: . The management who want the package and see and/or fear future IT developments. . The finance and logistics department who want to keep the package as simple and comprehensible as possible. . The IT deliverers of these packages who want to sell their package. . The IT department who manage all applications and want the package to fit in with other applications and want to adjust and maintain as few as possible.

P3 Find out how the value chain of the Greenery can be improved to deal with growing competition. (The Greenery is a cooperation of 7000 vegetable & fruit farmers, which owns 70 different companies in this value chain.) Likely stakeholders: 1. All 7000 farmers that cooperate in management. They desire to make more profit. 2. The management of the 70 companies who also want to optimize their profit. 3. Competition who want market share of the Greenery. 4. Other people in the value chain who want to keep their jobs. P4 Design an architecture for exchange of information about diagnosis-treatment combinations (DTCs) among insurance companies and hospitals. Likely stakeholders: 5. Insurance companies, who want to maximize profit by reducing the total amount that is claimed. 6. The hospitals, who want to offer the best treatments and help their patients the best they can (regardless of costs). 7. The patients, who want to have the best healthcare, paid by the insurance companies. 8. The government, who wants hospitals to make profit or at least play even. 9. The IT company that has to maintain and guard the data and wants to make profit and reduce risk.

P5 What is a good architecture for e-logistics systems, that can operate flexibly in different e-commerce environments and can incorporate different requirements of different business models used by partners? Likely stakeholders: 10. The ‘partners’ who want their own requirements satisfied by the architecture. 11. The problem owner (manager) that wants to link the partners and save money by the e-logistic systems and wants the systems to be able to operate flexibly in different e- commerce environments. 12. The IT department who have to maintain the systems, who want to keep it as straightforward and simple as possible.

P6 Develop an expandable and maintainable framework for an interactive web-based tool that can be used by SKF engineers that creates awareness about PDM by educating SKF engineers about PDM and about why SKF needs a PDM. Likely stakeholders: 13. PDM who wants to tightly connect the SKF engineers to them. 14. The SKF engineers who (are expected to) want to use a web-based service that PDM offers. 15. The IT department who wants it to be expandable and maintainable.

2. Answer the question on slide 12, using Alexander & Robertson’s checklist: Make a solution-stakeholder matrix for the Teletop (TT) System. - means that the stakeholder is negatively influenced by the solution. + means that the stakeholder is positively influenced by the solution. Solution The usability is Teachers can The lay- It is Which improved by add and out is easier to structure to adding automatic delete pages improve search for use is more links to other themselves d courses to clear to applications enroll teachers s

r Students + + + e d

l Teachers + + + + o

h IT dept - because of - + e k

a University higher costs for t

S maintainability Financial - because new - - - dept features cost extra University Customers + + + + + (high schools etc) TT - more work - - - Developers TT Managers + new income + + +

Chapter 7 – Goal Analysis 1. What is the difference between requirements and goals (if any)? According to Wieringa (slides chapter 7) “a goal is an end that a stakeholder wants to achieve”. In the slides from chapter 3 he states that “a requirement for X is a desired property of X” and that “requirements are desired solution properties”. This means that in contrast to requirements, goals are ends; after reaching it, the process is over. Requirements define the properties of the solution to reach that end, so are in the middle of the process. Only after implementing them one can reach his goal (if they were complete and adequate). Furthermore, requirements are prescriptive and describe expectations of stakeholders. The goal is not prescriptive but a state.

2. (Bossworth) Explain the difference between features and advantages in terms of customer goals. A feature is a property of a thing (let’s say Y). It is something Y has and what can be considered useful. When a seller considers it useful it is an advantage. So an advantage is an useful feature, but a feature does not have to be an advantage.

3. (Bossworth) A goal turns a latent need into a pain. Explain this. A buyer is not aware of a latent problem or need. It is somewhere in his background and he does not bother about it. Once he has a goal he wants to pursue, that means that he has to solve a need or problem in order to reach the goal. When he is aware of that need, it comes in his foreground, he becomes aware of it and it turns from a latent need into a pain.

4. Are preference relations always transitive? Explain. For each stakeholder, possible worlds are ordered by a preference relation that orders the utility of the world for a stakeholder (Wieringa, slides chapter 7). The definition of transitive is the following: transitive3 - Of or relating to a mathematical or logical relation between three elements such that if the relation holds between the first and second elements and between the second and third elements, it necessarily holds between the first and third elements. The relation of being greater than in mathematics is transitive, since if a > b and b > c, then a > c. This means that the answer is yes. Preference relations list preferences in order of importance, which means that if preference 1 is more important than preference2 and preference 2 is more important than preference 3, preference 1 is also more important than preference 3. This is transitive.

5. What is the difference between a goal tree and a means-end graph? Wieringa (slides chapter 7) says that: a “goal tree is a definition of a goal in terms of indicators, agreed with stakeholders”. “The tree is a definition, i.e. a convention” and “a means-end graph is a causal graph that shows causal relationships between goals believed to exist by a stakeholder” where the “nodes represent goals of a stakeholder” and an “arrow means that stakeholder believes that achieving the tail brings us closer to achieving the head”.

3 transitive. Dictionary.com. The American Heritage® Science Dictionary. Houghton Mifflin Company. http://dictionary.reference.com/browse/transitive (accessed: January 27, 2008). The difference therefore is that a goal tree has a root goal divided in indicators through which the goal can be measured as in Figure 10, whereas a means-end graph has a root goal divided in sub goals that much be reached before the root goal can be fulfilled, as in Figure 11.

Figure 10 - Goal decomposition tree (Wieringa, chapter 7, slide 15)

Figure 11 - Means-end graph (Wieringa, chapter 7, slide 32)

6. Answer the questions on slide 21.

Figure 12 - Questions (Wieringa, chapter 7, slide 21) According to Wieringa “norms cannot be found by investigating phenomena and have to be defined by stakeholders”. Furthermore, “norms can be violated by facts”, but “facts cannot be violated by norms”. - Forbidden to walk on the grass: norm - When a book is borrowed, this is registered: fact - The average soccer player weighs 90 kg: fact - A soccer game may last more than 2 hours: norm when we see it as a rule of the game, but fact if we see it as a phenomenon that appears. - You may leave: norm, when a teacher allows you to leave. - I might leave earlier: norm, when a teacher allows you earlier to leave. (But both are facts if we consider that you and I can still run out of the room, without allowance.)

7. Answer the question on slide 23: List goals of each type, applicable to you now. The following examples are given on slide 22 of chapter 7: Personal goals - I have to eat. - I want to be taken seriously - I want to do interesting work. Business goals - Explain mathematics clear to the student I help with their maths. - Sticker the catalogue of the products of my employer with barcodes to be able to sell easier on the fair next week. Task goals - Learn PASR theory and answer these questions. - Tidy up my desk. Legal goals - Pay my dentist bill - Be a good citizen

8. Which of the Berander’s and Andrews’ prioritization techniques were used by Alexander? Why did Alexander (not) use them? Berander and Andrews mention the following techniques: - Analytical Hierarchy Process (AHP) - Cumulative Voting, The 100-Dollar Test - Numerical Assignment - Ranking - Top-Ten Requirements Alexander used the numerical assignment when he divided the routes in three groups using triage, because that immediately reduced the number of routes with the impossible ones. I assume he used the same technique in his step ‘divide and conquer at centre nodes’, because he made two groups; one with routes from A to C and one with routes from C to B. This also reduces the complexity of the problem immense by using a relatively simple method. The step that he calls ‘hierarchical weighting’ is cumulative voting and a variant on the 100-dollar test. He used this in order to be able to give relative weight to the criteria of NATA, on which the project had to be weighted. His sensitivity analysis is not a technique described by Berander and Andrews because it is not a prioritization technique but an evaluation and validation technique. He consciously did not use Ranking, for which he mentions the following three reasons: 1. It is impossible to give relative weight. 2. There is a serious issue of the ‘fairness’ of the ranking, because some criteria have more child criteria then have more influence. 3. Projects vary widely so the proposed list by NATA cannot be used without critical remarks or adding (child) criteria. Furthermore, he also does not use AHP and top-ten requirements, but says nothing about the reasons not to chose them. However, he could have used AHP in my opinion, but the hierarchical weighting is more accurate because when comparing all possible routes he would have needed a criteria list to compare on as well. Then AHP requires more effort than cumulative voting. Top-ten requirements is not very effective because there are so many stakeholders that it is undoable. There are also some stakeholders incapable of giving their top-ten (such as the wildlife or the mansion) and the technique also is extremely coarse (Berander and Andrews, 2005).

9. Would you have used other techniques if you were Alexander? Why (not)? No, I would not. In my opinion he has firstly simplified the problem accurately by using numerical assignment which is clever to be able to deal with it when you have to use more difficult techniques. Also the cumulative voting is appropriate here, as far as it can be objective (as he also states), because it ‘objectively’ takes into account all criteria; also those of stakeholders that cannot come up for themselves (wildlife, mansion) and those that are not on the standard list of NATA. For the reasons mentioned above the other techniques are not (more) useful.

Chapter 8 – Problem Diagnosis 1. The problem bundle on slide 5 contains nodes that already hide goals.

Figure 13 - Problem bundle (Wieringa, chapter 8, slide 5) a) Which nodes? I would say all of them. The nodes are “problematic phenomena” (Wieringa, slides chapter 8) and I think that all problems incorporate a goal, because problems are gaps between experiences and desires of stakeholders and goals are desired ends. This means that all problems have the inherent goal not to have that problem. E.g.: For the problem “Value chain partners cannot access each other’s IS” the linked goal is to reach an end where all value chain partners can access each other’s IS. b) Why are they really goals? Because they reflect an end that a stakeholder wants to achieve. c) Is this a bad thing? No, as said before it is inherent on using problematic phenomena instead of neutral phenomena. A problem bundle is valuable because it links problematic phenomena. General phenomena that are not problematic do not need to be solved and therefore are not interesting to depict in a problem bundle.

2. Transform the problem bundle of slide 5 into a causal graph whose nodes are variables. According to Wieringa (chapter 7, slides Appendix A) “a variable is a property of an object (event, situation)” and, to make the difference clear with indicators, “an indicator of a property P is a measurable variable that has a systematic relationship with P”. In Figure 14 the graph is shown, whereby an arrow labeled with a ‘ – ’ means that if the variable at the tail of the arrow increases that the variable at the head of the arrow decreases and an arrow with a ‘ + ’ that if the variable at the tail increases, the variable at the head will increase too. Figure 14 - Causal graph with variables

Chapter 9 – Ill-structured Problems 1. A gap between experiences and desires is a problem if it is difficult to close it, and the stakeholders want to close it. Why are wicked problems different? According to Wieringa “a problem is wicked if it is a problem to investigate it – The problem is that it is a problem to determine the problem – A metaproblem! – Being wicked is a matter of degree” If a wicked problem is difficult to identify itself, that means that the gap is unclear to the stakeholders. That implies that stakeholders may not be aware of the exact problem, they might only have “a feeling of uneasiness” (Wieringa), so that means that they do not explicitly want to close it. A wicked problem is a gap between an experience (we have a feeling of uneasiness) and a desire (we want to know what the problem is), which is indeed difficult to close, but stakeholders may not want to close it because they are not aware of it (what Bossworth calls a latent need).

2. (Lindblom) The 1994 Chaos report mentions success and failure factors of projects. Relate the failure factors to the characteristics of policy problems identified by Lindblom. The Chaos report (1994) mentions the following failure factors: 1. Lack of user input 2. Incomplete requirements 3. Changing requirements 4. Lack of executive support 5. Technology incompetence 6. Lack of resources 7. Unrealistic expectations 8. Unclear objectives 9. Unrealistic Time Frames 10. New Technology Lindblom mentions five characteristics of policy problems: 1. Intertwining evaluation and empirical analysis. “One simultaneously chooses a policy to attain certain objectives and chooses the objectives themselves” (p82). This is caused by a ‘Lack of user input’ and therefore ‘Incomplete requirements’, as well as ‘Unclear objectives’, because all stakeholders disagree, are difficult to reach and it is difficult to find out what they actually want. Furthermore also circumstances of policies differ, so that answers to the same kind of questions differ. 2. Relations Between Means and Ends. “But it follows from all that has just been said that such a means-ends relationship is possible only to the extent that values are agreed upon, are reconcilable, and are stable at the margin. Typically, therefore, such a means-ends relationship is absent from the branch method, where means and ends are simultaneously chosen” (p83). Because of the combination of ‘Unclear objectives’ and ‘Incomplete requirements’ as discussed at the first point, means-end relations cannot be used. 3. The Test of "Good" Policy. Because of ‘Unclear objectives’, “Administrators cannot agree on values or objectives” (p83). 4. Non-Comprehensive Analysis. “Limits on human intellectual capacities and on available information set definite limits to man's capacity to be comprehensive” (p84) which is similar to the Chaos point ‘Technology incompetence’, which then includes also human incompetence. 5. Succession of Comparisons. “Policy is not made once and for all; it is made and re- made endlessly” (p86). This relates to ‘Unrealistic expectations’ and ‘Changing requirements’. “The attempt to push categorization as far as possible and to find general propositions which can be applied to specific situations is what I refer to with the word ‘theory’. Where root analysis often leans heavily on theory in this sense, the branch method does not.” This means that it is a problem in the root method to be flexible because requirements change over time. Trying to identify one policy for the rest of times is an unrealistic expectation.

3. (Lindblom) What are the characteristics of rational decision-making according to Lindblom? Lindblom defines five characteristics as shown in Figure 15.

Figure 15 - Characteristics of the rational-comprehensive method

4. (Lindblom) Why is it not useful to achieve a generally accepted agreement about preference ordering in policy-making? It is not useful to order preferences because stakeholders may not agree on the order, but may agree on the policy itself. Lindblom states that “the contestants cannot agree on criteria for settling their disputes but can agree on specific proposals” (p83). Therefore it is more successful, and therefore more useful, to compare concrete policies, as also Lindblom argues: “for many administrators will be quick to agree that the most effective discussion of the correctness of policy does take the form of comparison with other policies that might have been chosen” (p83).

5. (Lindblom) Lindblom does not agree with at least one of these statements: a) a means-end graph represents (belief in) causal relationships b) in decision-making, first you select an end, and then a means. With which statement(s) does he disagree? Why? What alternative does he give? With b. He says that that is the way it is done in theory by the root (or rational- comprehensive) method, but he argues that it is not necessary (nor possible) for policy making. He gives the alternative of the branch (or successive limited comparisons) method whereby means and ends are intertwined (what is a mean for one party can be an end for another) and were the criterion is agreement on the policy.

6. (Lindblom) Why is it possible that different stakeholders can disagree on goals but still agree on a solution? Because their ends and means differ. Discussing goals is the same as discussing ends and parties will not agree on the right ends. Some parties are more radical and see the end of another party as a means to come to a more extreme policy. However, both parties can agree on the solution of forming the end of the first party into a policy, because also the second party has come a step further in reaching its means and therefore has come closer to it’s ends.

7. (Lindblom) Policy-makers use knowledge from past decisions to guide them in their current decision. What is the difference with using a scientific theory? The scientific root theory is “continually building out from the current situation, step-by-step and by small degrees” (p80) and does not consider past knowledge or situations. As stated in the question the branch method is “starting from fundamentals anew each time, building on the past only as experience is embodied in a theory, and always prepared to start completely from the ground up”. Lindberg also states that “non-incremental policy proposals are therefore typically not only politically irrelevant but also unpredictable in their consequences”. This is a consequence of not using past experiences.

8. (Jones) What is the difference between the craftsman and the designer? Actually, Jones argues that the craftsman is a designer; the very first designer we had. However, he gives some differences between him and modern designers: - “Craftsmen do not, and often cannot, draw their works and neither can they give adequate reasons for the decisions they take.” - The craft product is developed in a process of trial-and-error over centuries. - Changes are made one at a time, even when a complete reorganization of the whole product would be more useful. - Essential information is stored in the form of the product and in exact memories, which is tacit knowledge. - “The shape of the product as a whole and the reasons for the shape, are not recorded in a symbolic medium and therefore cannot be investigated and altered without makeshift experiments with the product itself.” In other words: the knowledge why a product is designed in the way it is designed is not obvious or clear.

9. (Jones) With which of the problems of wickedness can craftmanship deal? Jones says that “the compatibility of a designed object with the situations in which it will be made and used is another question, and one in which designers are on weaker ground than craftsmen”. He means that craftsmen have a long experience of what works and what doesn’t work and what the customer likes and what he doesn’t like. This means that he can deal with the following problems of wickedness: . Goals may be mutually inconsistent; because he does not design a whole new system he knows that the goal of his product will be consistent and that the product will function. . Goals may not be operationalized; because he thinks from the product, goals are derived from the solution and therefore can always be operationalized.

10. (Jones) Map the stages of the engineering and architecture cycles give by Jones, to the regulatory cycle. The regulatory engineering cycle by Wieringa: 1. Problem investigation: what is the problem? a. Problem identification b. Problem definition c. Problem structuring d. Problem diagnosis 2. Solution design: Which solution alternatives are available? 3. Solution validation: Which alternative best solves the problem? 4. Solution implementation 5. Implementation evaluation: How well did it solve the problem? The sequences of Jones mapped to this cycle is depicted in Table 2. Table 2 - Stages of Jones compared to Wieringa's cycle Stage Engineering Architecture Comparing phase (Jones (Jones) (Jones) from regulatory cycle ) 1 Feasability 1. Inception Problem investigation Finding a set of feasible 2. Feasibility concepts 3. Outline Proposals 2 Preliminary design 4. Scheme Design Solution design Selection and development of the best concept 3 Detailed design 5. Detail Design An engineering description of the concept 4 Planning 6. Production Information Solution validation, Evaluating and altering 7. Bills of quantities Solution the concept to suit the 8. Tender action implementation and requirements of the 9. Project Planning Implementation production, distribution, 10.Operation on site evaluation. consumption and product 11.Completion retirement 12.Feedback

Chapter 10 – Solution 1. Answer the questions on slides 5 and 6 . What are the elements of each solution? . For each of the systems: what are the relationships among the elements that will cause the problem to be solved/reduced? According to Wieringa (slides chapter 10) “a system is a set of elements with relationships among them that have emergent properties”. As examples of elements he names physical elements, symbols and social elements.

1. E-business quick scan evaluation Elements are: - a list with criteria - the scores of an e-business - a list with norms Relationships among these: - the scores are per criterion, so can be mapped to the criteria what makes them say how an e-business scores on these criteria - the norms are also per criterion, so that they can be mapped to the criteria and to the belonging scores. This makes it possible to evaluate the e-business by comparing the scores to the norms.

2. IT-enabled procurement- and distribution process for Holland Casino Elements are: - Hardware - Software - Business processes - People Relationships among these: - The software runs on the hardware - It supports the processes step-by-step to make sure they are followed accurately - People use the software to carry out their tasks in the processes.

3. Cross-organizational logistics support system Elements are: - Different systems of the organizations - The software of the cross-organizational logistics support system - The hardware of the cross-organizational logistics support system - Logistical elements such as trucks - People Relationships among these: - The software runs on the hardware - The different systems are integrated and used by that software - The software supports the logistical tasks that people have to carry out. - It also steers the logistical elements.

Also the following solutions can be described in that way. 4. Information provision in PMC Valuables 5. A WFMS 6. A method for realizing IT-enabled change 7. Project management improvement proposal 8. Integration proposal for all administrative software of the company 9. A project monitoring database 10. CRM technology standards for the ING 11. Knowledge management technology opportunities 12. Internet opportunities

2. Fill out the table on slide 9 for the techniques that you know The following figure contains the relevant slides. Table 3 shows the filled out table for the techniques I know.

Figure 16 - Description of techniques (Wieringa, chapter 10, slides 8 and 9)

Table 3 – Other techniques described Service Behavio Communicatio Aggregatio Layer Audienc s r n n s e Use case diagram x x Collaboration x diagram Sequence diagram x Z x Lotos  ? CTL  ?

3. Answer the questions on slide 10 for the handout of these slides

Figure 17 - The pragmatics of specification documents (Wieringa, chapter 10, slide 10) . Who is the readership? Students. . What is it used for? Learning, teaching. . How is it maintained? During the duration of the course, by the teacher. . Can we throw it away? Now, we have it online as well. Unless we have notes on the handouts, then we can throw it away after receiving a final grade. . Who does document management? The teacher manages the slides, students print out their handouts themselves.

4. Which of these statements express assumptions and which express requirements? . This software will run on any Linux platform  assumption . This software should run on any Linux platform  requirement . The participant must have followed the database course  requirement . The database course requires no knowledge of programming languages  assumption.

Chapter 11 – Validation No questions

Chapter 12 – The problem-solving process No questions

Chapter 13 - Solving Knowledge Problems 1. For each of the validation methods listed by Zelkowitz: Describe the research problem and the research design.

Unclear questions I tried to answer all questions from the sheets to my best extent. However, some of them were really unclear to me. I especially doubt my answers to the following questions: - chapter 8, 1 - chapter 9, question 2. These five characteristics were not explicitly mentioned as policy problems by Lindblom. I rewrote them myself a little bit to be able to answer the question.

Recommended publications