Dr. Norbert Koppenhagen Chair of Information Systems IV, Business School, Institute for Enterprise Systems (InES), University of Mannheim SAP SE
Mannheim, September 10th 2014 13 10 Course Structure 4 Blocks 1. Introduction and Fundamentals of IS 2. Requirements Engineering and IS Development 3. Exercise Young IT Consultant 3 2 1 6 5 4 9 8 7 12 11 14 1. IS Project Management w/ Guest Talk 2. IS Implementation 3. Exercise Senior Manager 1. IS Delivery 2. IS Management 3. Exercise w/ Guest Talk, Experiment (9 & 10) 1. IS Use 2. IS Business Value 3. Exercise CIO Block A Block B Block C Block D Exam prep. 2 HWS 2014 - IS203 DeMIS, Section A.2 Goals of todays session You can identify, classify, and structure requirements You are able to gather requirements from the future users and stakeholders involved Understand differences between software development models
3 HWS 2014 - IS203 DeMIS, Section A.2 Todays session 4 Agenda 1 Introduction and Motivation 2 Definition of Software Requirements 3 Gathering Software Requirements 4 Managing Software Requirements 5 Software Development Approaches 6 Summary HWS 2014 - IS203 DeMIS, Section A.2 Development processes in the software industry 5 IS
Technology is the focus of this section of the lecture Especially application system aka software artifact
Social Sub-System Technological Sub-System Cannot be developed New artifacts can be developed (the design of alternative worlds) Often refer to structures from outside the working place (e.g., habits, culture) Require dedicated change effort (often gradual and over time) HWS 2014 - IS203 DeMIS, Section A.2 Two types of software artifacts Product Software Tailor-Made Standard software Custom software Generally purchased from vendor Service contract (Werkvertrag) Made to order or in-house purchase of things (Sachkauf) Characteristics Shared development costs Best-practices established Dev and maintenance by supplier Preview possible Documentation and education material available Reference implementation available Characteristics Tailored solution, focus on required functionalities only Competitive advantage Company-specific changes possible Independency of software supplier Terminology of company used, less education effort Source: adapted from Xu and Brinkkemper (2007) HWS 2014 - IS203 DeMIS, Section A.2 6 Tailored software project: dm point-of-sale software
Business challenge: Increasing centralization of trading companies Increasing international branches Application solution: Tailored software replaced standard software Easy-to-use touch screen Why did it work / characteristics: Simple complexity Flexibility more important than standard Benefits: Tailored software Centralized maintenance Source: Lambertz (2010) November 2006 First contact January 2007 First prototype Spring 2007 Contract June 2007 Start of implementing POS and servers in branches Fall 2007 Start of implementing central servers January 2008 Start of implementing coupon server August 2008 First productive branch January 2009 First 10 branches productive March 2009 First 100 branches productive April 2009 First business-day roll-outs May-July 2009 Main roll-out for more than 1,000 branches in Germany July 2009 Project piloting in Austria December 2009 Project complete HWS 2014 - IS203 DeMIS, Section A.2 7 Todays session 8 Agenda 1 Introduction and Motivation 2 Definition of Software Requirements 3 Gathering Software Requirements 4 Managing Software Requirements 5 Software Development Approaches 6 Summary HWS 2014 - IS203 DeMIS, Section A.2 Why requirements engineering matters The study of Hofmann and Lehner (2001) analyzed several IT implementation projects with respect to Knowledge Resources Top performers Performed RE throughout the project Invested twice the average effort to specify requirements Had a stable core team, which was supported by shared domain experts Source: Hofmann and Lehner (2001) Process Performance Fixing a requirements errors after delivery may cost up to 200 times the cost of fixing an implementation error Source: Davis (1993) HWS 2014 - IS203 DeMIS, Section A.2 9 What is a requirement? Requirements should state what the system should do Design should describe how the system does this The systems architecture is designed to support the requirements A requirement is: (1) a condition or capability needed by a user to solve a problem or achieve an objective (2) a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document (3) a documented representation of a condition or capability as in (1) or (2) Source: IEEE Std. 830-1998 HWS 2014 - IS203 DeMIS, Section A.2 10 Statements in natural language Supported by diagrams of the services the system provides and its operational constraints Written for customers User Requirements Structured document setting out detailed descriptions of the systems functions, services and operational constraints Defines what should be implemented Can be part of contract between client and contractor System Requirements Types of requirements HWS 2014 - IS203 DeMIS, Section A.2 11 Types of requirements Functional requirements Example Define the provided services Describe the system functionalities Describe the system behavior Describe the system reactions An bank online account must show the withdrawal transactions (date, time, location, amount) for the user-chosen period (e.g., 1, 3 or 6 months). Non-functional requirements Example Specification of quality of services Constraints on the services (e.g., timing constrains, fault tolerance, exception handling) When an account is queried, the response time must be below 2 seconds. HWS 2014 - IS203 DeMIS, Section A.2 12 Details and metrics for non-functional requirements A non-functional requirement may generate a number of related functional requirements Example: Security constraints generate functional requirements that restrict the access to functionality based on roles Non-functional requirements carry risks because they can affect the overall architecture in a non-intuitive way Example: To ensure performance, you may have to organize the system to minimize communications between components Property Measure Speed Processed transactions/second User/event response time Size Mbytes Number of ROM chips Ease of use Training time Number of help frames Reliability Probability of unavailability Rate of failure occurrence Robustness Time to restart after failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems HWS 2014 - IS203 DeMIS, Section A.2 13 Prioritization of requirements Definitions Examples Examples are contractual obligations, legal requirements or fundamental business functions Mandatory Requirements Fulfilling a business need Not implementing results in a loss of customer and revenue Drastic impact on business value Mandatory Requirements Examples are additional functions that are useful, but not needed during the main business process. Optional Requirements Less degree of urgency Implementing may result in additional business benefits Can turn into a mandatory one Optional Requirements HWS 2014 - IS203 DeMIS, Section A.2 14 How to precisely describe a software requirement? Precision Ambiguous requirements may be interpreted in different ways by developers and users (e.g. via systematic manual analysis and regular reviews) Completeness They should include the full set of requirements (e.g., what is the full set of information required?) Consistence There should be no conflicts or contradictions in the descriptions of the system facilities (e.g. left-right issue) In principle, requirements should be both complete and consistent In practice, it seems impossible to produce a complete and consistent requirements document Req-136: The financial calculation system should provide a right-hand sidebar (RS) with information about further functions in different languages. The RS is always displayed on the bottom left corner of the current page. What kind of information? System or math- functions? Which languages? Left or right?
Source: Sommerville (2010), Alavi (1984) HWS 2014 - IS203 DeMIS, Section A.2 15 Todays session 16 Agenda 1 Introduction and Motivation 2 Definition of Software Requirements 3 Gathering Software Requirements 4 Managing Software Requirements 5 Software Development Approaches 6 Summary HWS 2014 - IS203 DeMIS, Section A.2 Requirements Determination and Management We will use a somewhat simplified summary of this approach Requirements Determination Requirements Management Elicitation Validation Analysis and Specification Change Implementation Traceability HWS 2014 - IS203 DeMIS, Section A.2 17 Requirements Elicitation Discovers all facets of requirements Involves all the relevant stakeholders of the project Requirements Specification Classifies and organizes requirements Prioritizes and negotiates Covers functional and technical analysis Requirements Management Documents the history of accepting new requirements Changes or drops existing requirements Traces requirements implementation Requirements Validation Checks if the requirements actually define the system customers really want Requirements management tasks HWS 2014 - IS203 DeMIS, Section A.2 18 Requirements Elicitation Discovers all facets of requirements Involves all the relevant stakeholders of the project Requirements Specification Classifies and organizes requirements Prioritizes and negotiates Covers functional and technical analysis Requirements Management Documents the history of accepting new requirements Changes or drops existing requirements Traces requirements implementation Requirements Validation Checks if the requirements actually define the system customers really want Requirements management tasks HWS 2014 - IS203 DeMIS, Section A.2 19 Requirements Elicitation Elicitation allows the development team to dig for the customers requirements underlying the solution to be developed Successful projects reflect requirements that are derived from data from a variety of sources Elicitation provides grounds to systematically organize, synthesize, and rationalize the data Rationalizing helps to reduce the number of requirements that may be in conflict or redundant Elicitation is the process of drawing out a response from someone (e.g., a customer), either through questioning or observing HWS 2014 - IS203 DeMIS, Section A.2 20 Problems of elicitation Technical staff working with customers Stakeholders (end-users, managers, maintenance engineers, domain experts) Stakeholders often dont know what they really want Stakeholders express requirements in their own terms Different stakeholders may have conflicting requirements Organizational and political factors influence requirements The requirements change during the analysis process New stakeholders emerge The business environment may change Requirements elicitation / discovery Development team Project sponsors HWS 2014 - IS203 DeMIS, Section A.2 21 Which type of elicitation fits which objectives? Elicitation Techniques (suitable for) Express wishes Identify possibilities Impose real condition Identify market potential Interviews + - + o Use-cases o - + o Scenarios + o o - Personas o + - o Ethnography o o + o Survey, questionnaire o - + + Further details will be discussed and practically learned in the exercise session HWS 2014 - IS203 DeMIS, Section A.2 22 Be careful when talking to external sources One essential tool needed for opening dialogues about future plans with external sources is a non-disclosure agreement (NDA) The NDA legally binds third parties to hold information in confidence and not use it in a way that represents a competitive threat to the company Some companies include NDA clauses in their sales contracts between customers and partners NDA language is even present in most employment contracts HWS 2014 - IS203 DeMIS, Section A.2 23 Design Thinking Approach HWS 2014 - IS203 DeMIS, Section A.2 24 Source: HPI 2014 - http://www.hpi.uni-potsdam.de/d_school/designthinking/core_elements.html?L=1 Requirements Elicitation Discovers all facets of requirements Involves all the relevant stakeholders of the project Requirements Specification Classifies and organizes requirements Prioritizes and negotiates Covers functional and technical analysis Requirements Management Documents the history of accepting new requirements Changes or drops existing requirements Traces requirements implementation Requirements Validation Checks if the requirements actually define the system customers really want Requirements management tasks HWS 2014 - IS203 DeMIS, Section A.2 25 Requirements Specification Requirements classification and organisation Groups related requirements and organises them into coherent clusters
Prioritisation and negotiation Prioritising requirements and resolving requirements conflicts
Requirements specification Requirements are documented and input into the next round of the spiral
The requirements may be part of a contract for the system development and may be captured in a requirements document
Result is NOT a design document. It should set of WHAT the system should, do rather than HOW it should do it
HWS 2014 - IS203 DeMIS, Section A.2 26 Writing a requirements document Requirements document Explains why a product is needed Puts the product in context Describes what the finished product will be like
It should contain Introduction to document Description of product and functionality Listed requirements Appendices, glossary, references, index
Important input to validate requirements
Guides development and testing Source: Smith (2011) HWS 2014 - IS203 DeMIS, Section A.2 27 The requirements document Official statement of what the development team needs to implement Especially important in case an external contractor is hired Wide set of users and stakeholders If agile methods are being used, might grow with the project or be done for each iterative step
Source: Sommerville (2010) HWS 2014 - IS203 DeMIS, Section A.2 (1) Preface (2) Introduction (3) Glossary (4) User requirements specification (5) System architecture (6) System requirements specification (7) System models (8) System evolution (9) Appendices (10) Index 28 To extend natural language consider these Structured specifications Limits the freedom of the requirements writer Requirements are written in a standard way Might be too rigid for some requirements (e.g., business-oriented) Form-based Standardized forms are used to document each requirement Different layouts support the different requirement types Facilitates the requirements management process Tabular Used to refine or supplement natural language Useful when defining possible alternative courses of action Allows for quick overview over often lengthy descriptions
HWS 2014 - IS203 DeMIS, Section A.2 29 Users of a requirements document System customers Specify the requirements and read them to check that they meet their needs. Customers specify changes to the requirements. Managers Use the requirements document to plan a bid for the system and to plan the system development process. System engineers Use the requirements to understand what system is to be developed. System test engineers Use the requirements to develop validation tests for the system. System maintenance engineers Use the requirements to understand the system and the relationships between its parts. HWS 2014 - IS203 DeMIS, Section A.2 30 Problems with natural language HWS 2014 - IS203 DeMIS, Section A.2 Lack of clarity Requirements confusion Requirements amalgamation 31 Ways of writing requirements specifications Notation Description Natural language The requirements are written using numbered sentences in natural language. Each sentence should express one requirement. Structured natural language The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement. Design description languages This approach uses a language like a programming language, but with more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications. Graphical notations Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used. Mathematical specifications These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers dont understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract. Source: Sommerville (2010) HWS 2014 - IS203 DeMIS, Section A.2 32 Requirements Elicitation Discovers all facets of requirements Involves all the relevant stakeholders of the project Requirements Specification Classifies and organizes requirements Prioritizes and negotiates Covers functional and technical analysis Requirements Management Documents the history of accepting new requirements Changes or drops existing requirements Traces requirements implementation Requirements Validation Checks if the requirements actually define the system customers really want Requirements management tasks HWS 2014 - IS203 DeMIS, Section A.2 33 Requirements validation Requirement reviews Rapid Prototyping Development of an early, rudimentary version of system Includes essential features Assists when requirements are poorly understood Enable stakeholders to get experience Promotes discussion of unidentified features Common point of reference
Start early with developing test cases Having test cases already in the requirement specification can help to prevent future problems Test conditions and expected results need to be specified Expected results can help to validate the understanding of a requirement Systematic manual analysis Regular reviews during requirements definition Both client and contractor staff should be involved Reviews may be formal (with completed documents) or informal Communication between developers, customers, and users can avoid problems early Source: Sommerville (2010), Alavi (1984) Early Test Case Development HWS 2014 - IS203 DeMIS, Section A.2 34 Todays session 35 Agenda 1 Introduction and Motivation 2 Definition of Software Requirements 3 Gathering Software Requirements 4 Managing Software Requirements 5 Software Development Approaches 6 Summary HWS 2014 - IS203 DeMIS, Section A.2 Requirements Elicitation Discovers all facets of requirements Involves all the relevant stakeholders of the project Requirements Specification Classifies and organizes requirements Prioritizes and negotiates Covers functional and technical analysis Requirements Management Documents the history of accepting new requirements Changes or drops existing requirements Traces requirements implementation Requirements Validation Checks if the requirements actually define the system customers really want Requirements management tasks HWS 2014 - IS203 DeMIS, Section A.2 36 Requirements management Requirements management is the process of identifying, eliciting, documenting, analyzing, tracing, prioritizing, validating, and agreeing on requirements and then controlling implementation and change as well as communication with relevant stakeholders HWS 2014 - IS203 DeMIS, Section A.2 Source: based on Ruhe (2005) Requirements identification Establishing requirements repository Change management process and policies Traceability policies 37 Customer RM Ensures that customer requirements are recognized and implemented in products. Product RM Ensures sustainability and profitability of development by defining, prioritizing, and mapping product requirements from diverse sources. Project RM Analyzes and details product requirements and ensures implementation within the project boundaries customers have requirements in order to get solutions to their problems 3 perspectives on managing requirements Customer orientation products provide solutions to these customer problems and the corresponding requirements Product orientation New software is developed in projects with well-defined contents and schedules addressing product requirements Project orientation HWS 2014 - IS203 DeMIS, Section A.2 38 Managing Requirements: Traceability Traceability the source of each requirement is identified and linked back to the original customer requirement that was elicited
Testable defines that within one requirement there are no contradicting aspects, which makes the requirement per se not testable
Tracking in requirements databases:
In Practice, it often is important to know the source of the requirement and to ensure that it was tested. Req-ID Priority Description (short) Description (long) Origin Effort 147 High Need of a The system should DE-17 HWS 2014 - IS203 DeMIS, Section A.2 39 Tool support for managing requirements Formal requirements tracking software tools can help to gather, track, and manage requirements Help collect input, organize it, and maintain the source and other information for future use Some systems can automatically generate requirements documents Some systems provide ongoing communication about development progress back to the sources of the requirements
For more see: http://www.volere.co.uk/tools.htm HWS 2014 - IS203 DeMIS, Section A.2 40 Changing requirements Business and technical environment of the system often change after installation Introduction of new hardware Necessary to interface the system with other systems Business priorities change (with consequent changes in the system support required) New legislation and regulations may be introduced that the system must necessarily abide by The people who pay for a system and the users of that system are rarely the same people System customers impose requirements because of organizational and budgetary constraints These may conflict with end-user requirements After delivery, new features may have to be added for users if the system is to meet its goals
HWS 2014 - IS203 DeMIS, Section A.2 41 Todays session 42 Agenda 1 Introduction and Motivation 2 Definition of Software Requirements 3 Gathering Software Requirements 4 Managing Software Requirements 5 Software Development Approaches 6 Summary HWS 2014 - IS203 DeMIS, Section A.2 Evolution of Software Development NATO conference in Garmisch (1 st SE conference 1968) Software crisis The term software engineering (SE) appears Development of advanced techniques (object- orientation, spiral model for risk management) Further advances in SE (object- modeling, design patterns) New development trends (e.g., XP, Design Thinking, SOA) 43 HWS 2014 - IS203 DeMIS, Section A.2 Structured and agile development models Most development models can be associated with any one of the two major schools of thought
No right or wrong software processes Most projects include notions of both plan-driven and incremental Match characteristics to the development project at hand
Structured Agile Plan-driven Requirements-driven Sequential stages Iterative cycles Pre-planned Incremental Completing goals Approximating requirements One overall final product Series of intermediary releases 4 4 44 HWS 2014 - IS203 DeMIS, Section A.2 Structured models: Waterfall
Phased approach in a sequential fashion Analysis: Study, understand, and specify the system requirements Design: Study, understand and design the system architecture Implementation: Create individual code units and verify that each one fulfills its responsibility Testing: Integrate modules and the increasingly large system
Analysis Design Implementation Testing 45 HWS 2014 - IS203 DeMIS, Section A.2 Structured models: Waterfall 46 46 Analysis Design Implementation Testing Pro Contra Clear sequence of specific tasks Inflexible partitioning into stages Complete, well-defined products Insensitive to changing requirements Easy to manage process model High-risk due to big bang integration HWS 2014 - IS203 DeMIS, Section A.2 Paradigm shift Dissatisfaction with the overheads of structured models The aims of agile methods are to Reduce overheads in the software process (e.g., by limiting documentation) Be able to respond quickly to changing requirements without excessive rework Thus, agile methods Focus on the code rather than the design Are based on an iterative approach to software development Are intended to deliver working software quickly Evolve small pieces of quickly delivered software to meet changing requirements HWS 2014 - IS203 DeMIS, Section A.2 47 Agile models Family of development processes, such as Extreme Programming (XP) Scrum Focus on new paradigms in software engineering Rapid development Frequent releases Reducing process overheads Producing high-quality code They involve the customer directly in the development process Analyze a little, design a little, code a little
Analyze Design Code / Test 48 HWS 2014 - IS203 DeMIS, Section A.2 Agile models: Scrum Outline planning and architectural design Find and outline the requirements Identify the main abstractions of the software system and design the architecture Assess, Select, Develop, Review Assess the requirements, select and prioritise the most important ones, develop , review / test / bugfix Repeat the previous steps until all requirements are done
4 9 Outline planning and architectural design Project closure Assess Select Review Develop HWS 2014 - IS203 DeMIS, Section A.2 49 Agile models: Scrum Pro Contra Incremental development Frequent refactoring Strong communication with customer and in the team Often used as an excuse for lack of planning Functionality is broken down into manageable pieces Not (yet) feasible in distributed projects Rapid response to chance Only applicable to small sized systems Outline planning and architectural design Project closure Assess Select Review Develop HWS 2014 - IS203 DeMIS, Section A.2 50 What do we know about agile models Are widely believed to have positively impacted development performance
Mixed experience in practice suggest presence of important contingencies
Wide field of different studies Introduction and adoption Easy to adopt, but work only for certain types Human and social factors Inter-personal skills and trust required Perceptions of agile methods Very mixed experiences Comparative studies Each with unique strength and weaknesses Source: Dyb and Dingsyr (2009) HWS 2014 - IS203 DeMIS, Section A.2 51 Todays session 52 Agenda 1 Introduction and Motivation 2 Definition of Software Requirements 3 Gathering Software Requirements 4 Managing Software Requirements 5 Software Development Approaches 6 Summary HWS 2014 - IS203 DeMIS, Section A.2 Todays session in review 53 Correct and complete requirements are critical to projects success Different types of requirement exists and need to be differentiated clearly Gathering correct requirements is a process involving four basic steps Elicitation Analysis and specification Validation Management Have basic overview of development approaches: structured vs. agile HWS 2014 - IS203 DeMIS, Section A.2 Reflecting on your goals 54 Your goals Today HWS 2013 - DeMIS Section A.2 Questions, Comments, Observations 55 55 HWS 2013 - DeMIS Section A.2 Readings for block A Please prepare those readings until the exercise of block A
Subramanyam, R., Weisstein, F.L., and Krishnan, M.S. 2010. "User Participation in Software Development Projects," Communications of the ACM (53:3), pp. 137-141. Basili, V.R., Lindvall, M., Regardie, M., Seaman, C., Heidrich, J., Mnch, J., Rombach, D., and Trendowicz, A. 2010. "Linking Software Development and Business Strategy through Measurement," IEEE Computer (43:4), April 2010, pp. 57-65. Hofmann, H.F. and Lehner, F. 2001. Requirements Engineering as a Success Factor in Software Projects. IEEE Software (18:4), pp. 58-66.
Read them until 09/17/2013 HWS 2014 - IS203 DeMIS, Section A.2 Further related papers Optional readings in case you are interested
Rockart, J.F., Earl, M.J., and Ross, J.W. 1996. "Eight Imperatives for the New IT Organization," Sloan Management Review (38:1), pp. 43-55 Dyba, T., and Dingsoyr, T. 2009. "What Do We Know About Agile Software Development?," IEEE Software (26:5), pp. 6-9. Ulfelder, S. 2001. The dirty half-dozen six ways IT projects fail and how you can avoid them. Darwin Magazine (June), pp. 58-64. Cusumano, M., MacCormack, A., Kemerer, C.F., and Crandall, B. 2003. "Software Development Worldwide: The State of the Practice," Software, IEEE (20:6), November / December, pp. 28-34. Siau, K., Tan, X., and Sheng, H. 2010. "Important Characteristics of Software Development Team Members: An Empirical Investigation Using Repertory Grid," Information Systems Journal (20:6), November, pp. 563-580. Kauppinena, M., Vartiainenb, M., Kontioa, J., Kujalaa, S., Sulonena, R. 2004. Implementing requirements engineering processes throughout organizations: success factors and challenges. Information and Software Technology (46:14), pp. 937-953. Christensen, C. 2013. The innovator's dilemma: when new technologies cause great firms to fail. Harvard Business Review Press.
These readings offer you a more detailed perspective and will improve your individual knowledge base of this domain HWS 2014 - IS203 DeMIS, Section A.2 Next session: 09/17/2013 HWS 2013 - DeMIS Section A.2 References Requirements Engineering Alavi, M. 1984. An Assessment of the Prototyping Approach to Information Systems Development, Communications of the ACM (27:6), pp 556-563. Davis, A.M. 1993. Software Requirements: Objects, Functions, and States. Upper Saddle River, NJ, USA: Prentice-Hall. Glinz, M. 2007. On Non-Functional Requirements. Proceedings of the 15th IEEE International Requirements Engineering Conference, October 15-19, 2007. New Delhi, India. pp. 21-26. Hofmann, H.F. and Lehner, F. 2001. Requirements Engineering as a Success Factor in Software Projects. IEEE Software (18:4), pp. 58-66. IEEE. 1998. Recommended Practice for Software Requirements Specications, IEEE Std 830-1998, The Institute of Electrical and Electronics Engineers Kauppinena, M., Vartiainenb, M., Kontioa, J., Kujalaa, S., Sulonena, R. 2004. Implementing requirements engineering processes throughout organizations: success factors and challenges. Information and Software Technology (46:14), pp. 937-953. Ruhe, G. 2005. Software Release Planning, Handbook Software Engineering and Knowledge Engineering - Vol. 3, University of Calgary, Canada. Smith, R.S. 2011. Writing a Requirements Document. Published: n/a. Retrieved: 2011/09/23. Available at: http://www.cdl.edu/uploads/Qd/S6/ QdS615B1DcnwRZlnSuTDnQ/writing-requirements.pdf. Sommerville, I. 2010. Software Engineering (9th edition), Boston, MA, USA: Addison Wesley. HWS 2014 - IS203 DeMIS, Section A.2 References Development Basili, V.R., Lindvall, M., Regardie, M., Seaman, C., Heidrich, J., Mnch, J., Rombach, D., and Trendowicz, A. 2010. "Linking Software Development and Business Strategy through Measurement," IEEE Computer (43:4), April 2010, pp. 57-65. Cusumano, M., MacCormack, A., Kemerer, C.F., and Crandall, B. 2003. "Software Development Worldwide: The State of the Practice," Software, IEEE (20:6), November / December, pp. 28-34. Dyb, T., and Dingsyr, T. 2009. "What Do We Know About Agile Software Development?," IEEE Software (26:5), pp. 6-9. Lambertz, W. 2010. Erfolgreiche Eigenentwicklung, retail technology (2010:01), special reprint. Laudon, K.C. and Laudon, J.P. 2008. Management Information Systems: Managing the Digital Firm (10 th
international edition), Pearson. Siau, K., Tan, X., and Sheng, H. 2010. "Important Characteristics of Software Development Team Members: An Empirical Investigation Using Repertory Grid," Information Systems Journal (20:6), November, pp. 563- 580. Subramanyam, R., Weisstein, F.L., and Krishnan, M.S. 2010. "User Participation in Software Development Projects," Communications of the ACM (53:3), pp. 137-141. Xu, L., and Brinkkemper, S. 2007. "Concepts of Product Software," European Journal of Information Systems (16:5), pp. 531-541.