HyperStories: An Approach to Reducing Cognitive

Download PDF
0 downloads 0 Views 267KB Size Report
Comment
product owner. The team agreed to develop software in four-week iterations. The customer and the scrum master would work together to decide which stories ...
HyperStories: An Approach to Reducing Cognitive Load for Capturing, Communicating, and Maintaining System Requirements Aaron S. Read1,2 and Robert O. Briggs1,2 University of Nebraska at Omaha Center for Collaboration Science

1

2

[email protected], [email protected] Abstract. Conventional system requirements provide thorough details of a system, but impose high cognitive load. Agile stories allow customers and developers to more easily negotiate the requirements by imposing lower cognitive load. However, stories may lack sufficient detail to capture the nuances of stakeholder win conditions. This paper reports a design science study to derive an artifact for documenting system requirements that imposes lower cognitive load than conventional requirements, yet provides more detail about stakeholder requirements. The study draws on the Time Based Resource Sharing Theory of Working Memory to derive a new requirements notation called HyperStories, which significantly reduces the number of information cues required to capture a set of requirements. We present the evolution of the HyperStory through several design iterations during a large-scale software development project. We demonstrate the reduction in cognitive load through a quantitative comparison of the information cues required by HyperStories vs. conventional requirements. Keywords: HyperStory; Cognitive Load; Agile Software Development; Requirements Engineering

1 Introduction Information systems projects continue to be troubled by low success rates (Rubenstein 2007). Defects in system requirements account for a major portion of these failures (Hofmann and Lehner 2001). It is a cognitively demanding task to assure the correctness, completeness, and consistency of requirements for complex systems. It is not uncommon for a large-scale system to have tens of thousands of requirements with complex interdependencies. Requirements can be made more manageable by representing them systematically with modeling and structuring techniques (Damm and Harel 2001; van Lamsweerde 2001; Sutcliffe 2003; Desai, Mallya, Chopra and Singh 2005). Modeling a system may require extensive up-front effort to discover and document requirements. Much of this work may be wasted, however, because it is common for requirements to change during the course of a large-scale systems project as the business environment evolves and as stakeholders gain new insights about their

problems and possible solutions. Requirements must be rewritten, stakeholders must validate them, developers must be made aware that plans have changed, and test cases must be rewritten. In some cases many specifications may be affected by a change of a single requirement. Because of the complexity and importance of system requirements to the success of a systems project, the interpreting, updating, and the presentation of system requirements has been the subject of much study (Basili and Filippo 1999). Agile software development methodologies try to minimize the cognitive effort of creating and maintaining system requirements by keeping documentation to a minimum. These methods often capture a high-level summary of a requirement as a story —a one sentence description of a user’s interaction with some feature of the system (Beck and Fowler 2000; Cohn 2004). In agile methodologies, details of the requirements are meant to be communicated directly between the developers and the customers as the software develops. This allows requirements to be moved very quickly from the intentions of the customer to the development of software without going through the effort of formal specifications. For this approach to work, developers and customer must be co-located and must invest considerable time in face-to-face conversations. The details of their agreements may not be formally captured and validated. This opens the possibility for misunderstandings during meetings and forgotten details during development. With minimal documentation, there is no robust means of assuring that the functionality developed traces back to requirements. A large body of work investigates the degree to which different reading methods improve the performance of inspectors in detecting requirements defects(Basili and Filippo 1999). Research in the formulation of requirements has presented methods of modeling requirements that are also intended to reduce errors in developing software (Mayrhauser and Vans 1995; Storey, Fracchia and Muller 1997). These works, however, leave open the question of how the design artifacts themselves could be altered to reduce the cognitive load of executing tasks relating to requirements. It would be useful, therefore, to establish a theoretical basis for such enquiry, and to examine the question empirically. In this paper, we report a design science study to derive a new kind of artifact for documenting system requirements that imposes lower cognitive load than conventional specifications, yet provides more details about stakeholder requirements. The study draws on the Time Based Resource Sharing Theory of Working Memory (TBRS) (Barrouillet, Bernardin, Portrat, Vergauwe and Camos 2007) and uses a design science (Hungerford, Hevner and Collins 2004) approach to derive a new requirements notation called HyperStories in order to address the tension between cognitive load and requisite detail.

2 Theory In the education literature, cognitive load is classified as extrinsic, intrinsic and endogenous (Sweller, van Merrienboer and Paas 1998). Researchers use this

classification scheme to focus on eliminating material that contribute to cognitive load but do not contribute to understanding. However, this classification scheme does not provide insight into the cognitive mechanisms that give rise to cognitive load. The Time Based Resource Sharing model of working memory (TBRS) proposes such mechanisms (Barrouillet, Bernardin and Camos 2004; Barrouillet et al. 2007). Unlike earlier cognitive models, TBRM proposes that working memory has a single central processor that is single threaded – it can only complete one operation at a time. The central processor must divide its time among several tasks, among them processing information cues, fetching things from long term memory, pushing things from working memory to long term memory, processing concepts in working memory, and refreshing the contents in the contents of working memory. Items held in working memory fade in a few seconds and must be refreshed by the central processor to keep them active in working memory. Each of these operations requires some amount of time, so there is a limit to how many operations can be executed in a given time slice before concepts start to drop out of working memory. According to TBRS, cognitive load is defined as the proportion of time the processor is busy doing other things than maintaining items in short term memory. It can be represented by the equation: CL = ∑ aN/T where N represents the number of operations, a represents the difficulty of those operations, and T is the time taken for a set of operations. If the logic of TBRS holds, then the number of information cues necessary for a person to complete a task pertaining to system requirements would directly affect the cognitive load imposed by the task. As information cues increase, the number of fetches and pushes to and from long-term memory would also increase, which could cause a cascading of cognitive load. The less expertise or understanding a person had of the information cues, the more difficult the processing those cues would be, and so cognitive load would increase.

3 Method We used design science to evaluate the HyperStory’s and HyperEpic’s ability to reduce cognitive load (Hevner, March et al. 2004). Design science seeks to build knowledge and extend organizational capabilities through the creation of innovative artifacts. Researchers use theories to inform the design of these artifacts. In the current case, TBRS was used to derive design guidelines for requirements artifacts. Each time an action using the HyperStory format resulted in an unsatisfactory outcome, TBRS was used to investigate ways to improve the design. A solution was then implemented. The HyperStory underwent five design/test/build cycles. At the beginning of each design cycle, we interviewed stakeholders who worked closely with the HyperStory about their experienced cognitive load using the requirements artifacts. These interviews, in addition to our own experience designing the HyperStory are recorded in each design iteration listed below. The artifacts were

analyzed in light of user reports and design guidelines derived from TBRS which are mentioned below. As cognitive load increased, the time necessary to complete a task would also increase. These two insights TBRS become the basis for design principles with which to improve the representation of system requirements in documents: 1.

Reduce the number of information cues to be read for a reading - based task

2.

Reduce the reading difficulty of information cues in system requirements Only provide details to people who need them, and only at the time they need them. Eliminate redundancy where doing so does not increase cognitive load.

With TBRS and these design guidelines, we worked with stakeholders and developers on a large-scale software project to derive a new way to represent their requirements that would reduce cognitive load and time on task for writing, reading, and requirements. Because cognitive load appeared to be at the core of the requirements bottleneck for the project, we use the Time-Based Resource Sharing model as explained above to approach challenges of representing many details associated with stories. Each design iteration began with an action taken using the current HyperStory artifact and work practices. These were used in the normal course of work of developing the requirements for the software and resulted in an unsatisfactory outcome. We were then presented with a design challenge to change the HyperStory method so that a satisfactory outcome would result. We then developed a solution that resulted in changing the HyperStory method. We present the design iterations that lead up to the current design method (presented in Figure 1), delineating the action taken, outcome, challenge, and solution for each iteration. 3.1 Case Background A group of stakeholders agreed to build a new rapid development environment for collaborative software applications called ActionCenters. Drawing on experience with earlier prototypes, they anticipated the project would require approximately 500,000 to 1,000,000 lines of new code. The team had a budget of $4,000,000 USD, which they anticipated would only be sufficient to build the core functionality of the proposed system. Further funding would depend heavily on the degree to which the organization could derive value from first round of development. The ActionCenters project team consisted of a one customer representative, a system architect, four full-time senior developers, two part time developers, a UI designer, and a story master. Each professional team member teamed with an intern/mentee. Part way through the project, testing team formed consisting of a test lead and two testers. The Project. The customer had been involved in developing the requirements for an earlier full-scale prototype of the system. None of the prototype code could be used in

the production version of the system because the team decided to implement the new system on a different technical platform. None of the developers of the prototype system were involved in developing the production version. Full formal specifications for the prototype system existed. The customer and the prototype development team had spent a year writing those specifications before coding began. Those specifications could not be reused, however, because they were too closely tied to the original development platform. The team found that it was not possible to reverse engineering the requirements and constraints from the detailed system specifications. The customer had a detailed understanding of what the capabilities and constraints of the system should be. Those requirements remained stable over the life of the project. Selection of an Agile Software Development Methodology. At the beginning of the project, only the customer knew the system requirements. The customer had other duties in addition to the project, and so could not devote full time to communicating the requirements to the development team. The customer and development team therefore agreed to use an Agile development approach for the project hoping to eliminate the cognitive load associated with writing formal specifications. None of the team had previous experience with Agile methodologies. The development team established work practices based on the Scrum Agile Software Development method (Highsmith and Cockburn 2001). The architect also served as the scrum master. The customer and the architect shared the duties of the product owner. The team agreed to develop software in four-week iterations. The customer and the scrum master would work together to decide which stories should be implemented in each iteration. Each iteration would begin with a one-to-two day planning meeting where the stakeholders would review what had been accomplished and learned in the previous iteration. Then developers would estimate the level of effort required for stories to be built in the next cycle. Developers made their estimates in terms of story points (Cohn 2004). A story point roughly equated to a half a day of work for a single developer. During each iteration, developers held a daily 15 minute stand-up meeting to report what they had achieved the previous day, what they would achieve that day, and what barriers they faced. Creation of the Story Master Role. The customer originally agreed to write the stories for the project. However, the customer had responsibilities outside the project, and so did not have enough time to write well framed stories during each sprint. The team therefore created a new role they called ―story master‖ and hired a person to work with the customer to capture and document stories and enter them into an online story management system.. The principle duty of the story master was to assure that the development team had stories to estimate at the beginning of each iteration. The story master therefore participated in design meetings with the customer and UI desginer, and made notes about the design decisions and agreements they achieved. The story master worked with the customer and the scrum master to decide which stories should be executed in the next iteration. The story master wrote acceptance tests for each story the developers committed to build during a sprint. In the early months of the project, the story master typically spent 15-20 hours a week in the role.

User stories proved an efficient means of capturing requirements in just enough detail to allow the customer and developers to get a rough overview of what functionality needed to be included in a certain component of the software. The customer and developers had a sense of how thought out a piece of software had become by the extent to which stories had been written about it. The customer and scrum master found it took only an hour or so per month to prioritize proposed and decide which stories should be executed in the next iteration. A tension between detail and cognitive load. Because the customer had an in depth knowledge of the requirements, because resources were scarce, and because future funding depended on early success, there was pressure to assure that requirements were reflected correctly in the software in detail the first time they were built. Details were therefore also an important part of the estimation process. The specific details behind a user story could have a large impact on development efforts. For example, the customer included an undo functionality as part of a user story to be able to delete certain objects. The undo functionality added an additional 20 points to a story that would have otherwise taken 5 story points. On the other hand, the customer had limited time to devote to the project. He could spend no more than 10-14 hours a week (on average) on requirements. Much of this time was devoted to making design decisions about how requirements should work be realized in the software, especially the user experience. These discussions produced stories that summarized decisions. For example: In the Project Explorer, a Collaboration Engineer creates a new project in order to develop a new application. The new project appears on the Project List. The stories did not capture the nuances of the design decisions about, for example, the variety of ways a collaboration engineer could create a new project, what the project list would look like, or how it would behave. At the end of the second iteration, the developers delivered working software that would allow a user to create a new project. The customer, however, expected five ways to initiate the create action – a button click, a right click menu, a regular menu choice, a keyboard shortcut, and a drag-and-drop action, because all these concepts had been discussed in the design meeting. When the customer raised the question during the retrospective review, a programmer said, ―It wasn’t in the story, so I didn’t build it.‖ The customer felt strongly that the story approach would not be sufficient to capture the ―many nuanced and fault intolerant‖ requirements of the system. Details of requirements and specifications were also important to the testing process. The test team could not assure that each function performed in a way it should without some standard against which to verify it. The customer therefore decided to write full specifications for the next iteration. Three days into the effort, however, he realized that he did not have nearly enough time available to produce full specifications each month, and that the project was, therefore at risk. The stakeholders met to explore alternatives that would produce the system the customer wanted without having to resort to formal detailed specifications.

3.1 Development of the HyperStory Approach First Iteration: Removing Repetition by Using Variables Challenge: The details were very time consuming to write and verify. Several of the test cases would vary by only one word or one phrase. As recommended by TBRS, there was an opportunity to reduce the number and difficulty of information cues needed to write and understand the details, since much of the information about the requirements was unnecessarily repeated. Solution: These were first dealt with by including ―repeat for:‖ phrases. For example, the functionality of creating an object from a context menu needed to work for an activity, phase, role, or screen. So an example of this would be ―A user can create an activity by right clicking and activating a context menu. Repeat for: phases, roles, and screens.‖ It was then discovered that repetitions happen in conjunction with certain parts of the description of the functionality. Several different user interactions with the software resulted in the same behavior from the system. These user interactions were labeled INITIATION. The resulting behavior of the system was labeled SUCCESS, and any user input that resulted in this behavior was written to result in SUCCESS. The following is an example of how these would be used: INITIATION = new row appears after item with focus. The cursor is in the activity name cell. Text appears in the cell saying, "Type Activity Name Here.‖ Click Add Activity= trigger INITIATION Right Click phase = trigger INITIATION Press Insert = trigger INITIATION Following INITIATION, User types input followed by enter. SUCCESS. SUCCESS = Activity added Second Iteration: Using Pseudo Code to Reduce Repetitive Stories Action: A pseudo code format was used to assure consistency of functionality. The functionality of a user story could be initiated in several different locations, in several ways, and could apply to several objects. Nested for loops would be used to represent different variations of locations, initiations, and objects. Outcome: This method of structuring variables worked well for a number of straight forward stories. It then became unreadable for complex stories. To understand which initiations were included in a HyperStory, the entire nesting pattern needed to be followed to piece together what details were implied. Challenge: We needed to come up with a method of structuring the variables related to a particular story that involved a structure that did not require much effort to follow. This effort to follow the structure required processing information cues, leading to cognitive load. Even without any quantitative analysis of the number of information cues present in the two formats, it became apparent that the pseudo code produced a strong negative affective response in one of the customer, and he decided to discontinue the task. It was very difficult to assure that the pseudo code would

accurately represent all the details of the requirements. For example, it was difficult to assure that each permutation in the for loop was properly accounted for, as well as whether or not the nesting of the for loops was correct. This made both constructing and reading the pseudo code representation of the requirements difficult. Solution: Finally, when discussing the need to represent functionality without repetition with the development team, a member of the development team suggested that a markup language be used to label variables in a user story, such as locations, initiations and objects. We found that when we represented requirements this way, it was very easy to assure that all details of the requirements were represented. To assure that each detail was properly included, one was first alerted by the tagging mechanism, the brackets ―[]‖ of a part of the user story that was going to vary. For example, ―A Collaboration Engineer can [initiate an edit] of an activity.‖ Then the word or phrase inside the brackets (―initiate an edit‖) was searched for in the list of parameters. Finally, the list of possibilities for the particular variable was inspected for completion. A user story with brackets to mark up parts of the story that could vary, along with the parameters containing the values of how the user stories varied is the essence of a HyperStory. Third Iteration: Constraining Requirements Action: As we considered the HyperStory in the texting context, we realized that while a HyperStory could represent dozens of actual statements about the system. Outcome: Not all of these statements represented by a HyperStory were true. Additional information was needed to constrain these statements. Challenge: We needed to come up with a way to represent constraints on HyperStories without requiring the reader to navigate a complicated structure. Solution: Business rules became a section of HyperStories. Business rules were also often the most important details of stories. The story master could derive many of the other details about requirements if the business rules were known. This was likely because many requirements were simply slight mutations of other requirements. When the business rules were known, any exceptions resulting from these permutations could be understood. We found that in some cases, if business rules were known, much of the details about the HyperStories could be derived by the story master without the customer’s help. Forth Iteration: Grouping HyperStories into Epics and Refining the HyperStory Method for Writers Action: As we introduced business rules, the grouping of requirements became important. Outcome: We noticed that parameters as well as constraints applied to a certain group of stories. Challenge: We needed a way to group HyperStories so that we could bound the extent to which business rule or constraints and parameters could apply. Solution: These groups of HyperStories became epics. The HyperStory format would have helped a lot in previous iterations to be able to understand what was just a detail, a business rule, or what was a story. In the beginning, everything was captured without distinguishing between what type of information it was.

Several needed improvements would arise as the HyperStory was used. Parameters can be used within parameters, when items inside parameters also contain repeating parameters. We found, however that this should not extend to three levels of parameters. It becomes too difficult to trace the parameters to lower levels. Parameters lists became lengthy and difficult to search. They were then alphabetized to make searching for a parameter easier. The values of parameters were put in bullets to make them easier to find as well. Fifth Iteration: Refining HyperStory for the Readers (Developers) Action: The project management software used for the ActionCenters project, VersionOne presented the developers with a list of story titles that functioned as the backlog. This software therefore constrained the way that the epics and HyperStories could be presented to the development team. They had to be broken down into individual stories. The HyperStories were presented to the scrum master grouped into epics. The scrum master then broke down the epic into individual stories. He needed to do this, since some developer expertise was needed to understand the best way to break up the coding effort. The details of each user story were attached by copying the entire epic into the details section of the story in the VersionOne software. Outcome: The customer noticed that none of the details in the epics were being read by the developers during the sprint planning meetings. The scrum master who worked closely with the developers confirmed this. Additionally, the copies of the epics could not be updated concurrently. They became difficult to maintain and the developers did not trust that the epic held the most up-to-date information. Challenge: We needed to reduce the cognitive load of understanding the details of an epic from the developer’s point of view. Solution: The order of information within the HyperStory was changed to HyperStories, parameters, and then business rules. When the developers read the HyperStories, they spent the least amount of time reading the business rules. We also considered that the parameters made the epics unnecessarily difficult to read, since their significance was not understood until the actual HyperStories were read. We are also currently devising a method of delivering the stories to the developers that allows us to break down the epics into single HyperStories that contain only the marked up story and the parameters needed for the HyperStory. A link to a wiki where the Epic for the HyperStory would also be included so that the developer could see the most up-to-date version of the HyperStory, along with the business rules needed that constrained the behavior of the story. The current design of the HyperStory in an epic is depicted below. EPIC: STORY: In , , . END STORY PARAMETERS:



[]: ;  []: END PARAMETERS

;

BUSINESS RULES:   END BUSINESS RULES END EPIC HyperStory Syntax: A HyperStory consists of a user story in the following structure: In , a user can perform , to create for . Parameters are used any time to eliminate repetition. A parameter is represented by putting brackets around the element of a statement that can vary in two or more ways. The details of the outcomes of a HyperStory are listed below the story in a bulleted list. Different the HyperStories are organized into epics. Within an epic, the HyperStories are written first. Then all parameters The business rules that constrain the behaviors of the HyperStories within the epic are listed last. The following contains two example HyperStories organized into a HyperEpic. The same information contained in the ―Open Element Editor‖ HyperStory is also illustrated below.

EPIC: Open and Close editors in the CACE STORY: Open Element Editor [In a CACE component], a CE can [perform an opening action] to reveal the element editor for an object.  The element editor for the object being edited appears as a new tab underneath the center window of the explorer pane  All fields associated with the element appear in columns in the element editor.  The first field is selected for editing  Fields with initial values configured contain those initial values.  Any categories of fields closed when the element editor was closed are closed  Any categories of fields left open for editing from a previous session are open END STORY STORY: Close Element Editor A CE [closes] an editor. The element editor for the object closes. END STORY PARAMETERS

[A CACE component]: Explorer Tree; ActionCenter Builder; Screen Editor; [Closes]: right clicks element editor tab and selects close; clicks the close button on the element editor [Perform an Opening action]: Right click project; right click phase; right click activity; right click role; right click screen; right click tool END PARAMETERS BUSINESS RULES  Closed/opened categories are remembered from state to state, are particular to a CE  Categories of fields are not group enabled END BUSINESS RULES END EPIC

In the ActionCenter Builder, a CE can right click a phase, to reveal the element editor for the object to edit its properties.  The element editor for the object being edited appears as a new tab underneath the center window of the explorer pane  All fields associated with the element appear in columns in the element editor.  The first field is selected for editing  Fields with initial values configured contain those initial values.  Any categories of fields closed when the element editor was closed are closed  Any categories of fields left open for editing from a previous session are open In the actionCenter Builder, a CE can right click an activity , to reveal the element editor for the object to edit its properties. (Repeat Outcomes) In the ActionCenter Builder, a CE can right click a role, to reveal the element editor for the object to edit its properties. (Repeat Outcomes) In the ActionCenter Builder, a CE can right click a tool, to reveal the element editor for the object to edit its properties. (Repeat Outcomes) In the ActionCenter Builder, a CE can right click a screen, to reveal the element editor for the object to edit its properties. (Repeat Outcomes) ….

4 Analysis 4.1 Quantitative Analysis We present a brief quantitative analysis of the HyperStory here to illustrate how it may reduce cognitive load according to the TBRS model. Considering the examples of the requirements written in HyperStory format within an epic and the same requirements written without markups or parameters, there is a dramatic reduction in information cues moving from the requirements written without parameters to the HyperStory. If each word counted as an information cue, 108 words or cues are present in the HyperStory format. In the ―flat‖ story format, 20 times 102 information cues, there would be 2040 information cues to process. Our design principles consider the number and difficulty of information cues needed to perform a particular task, which does not necessarily require processing all of the information cues. A verification task, where the customer needs to examine the requirements to be assured that no requirements are missing or incorrect does require examining every information cue. A maintenance task may not require all cues to be read. However, the HyperStory format will very frequently reduce the number of information cues to process for this task. 4.2 Some Effects of the HyperStory on the Software Development Project As a result of incorporating more detail into user stories using the the HyperStories, the customer was in a in a much better position to explain to them what is expected in the planning meeting. The customer observed that Number of points committed to by the developers in the sprint planning meetings went up—perhaps because the increased number of details discussed reduced uncertainty of what it was going to take to build to a story. When more certain, more willing to commit to more points. The increase in details using HyperStories is also increasing the number of details that can be used to create tests which verify whether or not the software will work the way the customer desires.

5 Discussion We have presented the HyperStory, a method of incorporating details into user stories used in Agile Software development methods, developed using design principles based on the Time-based resource sharing model of working memory. This method allows the customer to communicate more details of requirements to developers with less cognitive load. We have illustrated here how these design principles guided the development of the HyperStory through several design iterations where challenges faced in a software development provided motivations for improvements to the

format. We also presented a quantitative analysis of the information cues present in a HyperStory as evidence of a reduction in cognitive load. The design of the HyperStory has led to some structuring that is similar to other forms of structuring requirements. Aspect in aspect oriented software development (Baniassad and Clarke 2004), for example, uses symbols to markup parts of the requirement, in conjunction with parameters. Such a method similarly allows for a easier update and verification as does. However, aspects build on the idea of separation of concerns and modularity as design principles. The work here builds on more general principles—reducing cognitive load through fewer information cues that are easier to process. The success of the HyperStory may also explain why Aspects work so well. Our approach is also different in that there is no formal process for choosing what should be modularized or parameterized. Such a flexibility reduces the learning curve of the HyperStory method. In the quantitative analysis, we only assessed the number of information cues in the HyperStory, we did not assess the difficulty associated with processing the information cue. Such an analysis would require that we know the task in which the information cues would be known. We would also need to have a greater understanding of what makes it difficult for an information cue to be processed. These are topics for future research. With such an understanding, we will be able to develop and perform experiments where participants There are several potential reasons why information may be difficult to process which are not inherent in the document itself. The level of understanding held by the person working with the documents makes information cues much easier to process. The developers did not trust the requirements at one point because they were not upto-date. Perhaps a partial unwillingness to process information cues can make them difficult to process. There are design constraints that may dictate the way information is presented, aside from reducing the number of information cues and reducing the difficulty of processing those cues. Many of these constraints likely arise from other software tools that must be used by development teams to communicate requirements. Other arbitrary constraints from the demands of other stakeholders in the organization. Future research should also investigate the nature of these arbitrary constraints.

References Baniassad, E. and S. Clarke (2004). Finding aspects in requirements with Theme/Doc, Citeseer. Barrouillet, P., S. Bernardin, et al. (2004). Time Constraints and Resource Sharing in Adults' Working Memory Spans. Journal of Experimental Psychology General 133(1): 83-100. Barrouillet, P., S. Bernardin, et al. (2007). Time and Cognitive Load in Working Memory. Journal of Experimental Psychology: Learning, Memory, and Cognition 33(3): 570-585. Basili, V. R. and F. L. Filippo (1999). Building knowledge through families of experiments. IEEE Transactions Software Engineering 25(4): 456-472.

Beck, K. and M. Fowler (2000). Planning Extreme Programming, Addison-Wesley Longman Publishing Co., Inc. Cohn, M. (2004). User Stories Applied: For Agile Software Development, Addison Wesley Longman Publishing Co., Inc. . Damm, W. and D. Harel (2001). Breathing life into message sequence charts. Formal Methods in Systems Design 19(1): 45-80. Desai, N., A. U. Mallya, et al. (2005). Interaction protocols as design abstractions for business processes. IEEE Transactions Software Engineering 32(12): 1015-1027. Hofmann, H. F. and F. Lehner (2001). Requirements Engineering as a Success Factor in Software Projects. IEEE Software 18(4): 58-66. Hungerford, B. C., A. R. Hevner, et al. (2004). Reviewing software diagrams: a cognitive study. Software Engineering, IEEE Transactions on 30(2): 82-96. Mayrhauser, A. v. and A. M. Vans (1995). Program comprehension during software maintenence and evolution. IEEE Computer(August): 44-55. Rubenstein, D. (2007). Standish Group Report: There's Less Development Chaos Today. Software Development Times, from http:// www.sdtimes.com/content/article.aspx?ArticleID=30247. Storey, M.-A. D., F. D. Fracchia, et al. (1997). Cogntiive design elements to support the construction of a mental model during software visualization. The Proceedings of the 5th International Workshop on Program Comprehension (IWPC’97), Dearborn, Michigan. Sutcliffe, A. (2003). Scenario-based requirements engineering. Requirements Engineering Conference, 2003. Proceedings. 11th IEEE International: 320-329. Sweller, J., J. van Merrienboer, et al. (1998). Cognitive Architecture and Instructional Design. Educational Psychology Review 10(3): 251-296. van Lamsweerde, A. (2001). Goal-Oriented Requirements Engineering: A Guided Tour: 249.