Not Signed-In
Which clippings match 'Design Solutions' keyword pg.1 of 1
21 MARCH 2013

Design Prototypes as Boundary Objects in Innovation Processes

"In our paper we focus on how design prototypes can foster communications in organizations that deal with the development of innovations. We distinguish the impact of prototypes between two different organizational levels; we first conduct the impact of prototypes at the level of organizational design teams that develop ideas and concepts for solutions. We then focus on the impact of prototypes on the level of organizational teams and departments that have not been part of the initial design phase but are responsible for further developments in the innovation process, e.g. production, financing, and marketing.

Previous research has indicated that prototypes have a significant influence on both organizational levels. Prototypes, in the best cases, can become so–called boundary objects between different domains and stakeholders and may deliver positive effects within the innovation process. However, the successful management of stakeholders in this context remains highly challenging. In this paper we want to address these difficulties as well as the current state of research in this field. We propose that a prototype does not only stand for an important design technique but should moreover be regarded as a management tool that can be integrated into a structured dialogue between stakeholders. We provide first insights on what a structured dialogue, based on prototypes, can mean and what it thereby should imply. We will synthesize prior research findings and begin to develop a concept on how to utilize prototypes as boundary objects from a management perspective."

(Holger Rhinow, Eva Köppen and Christoph Meinel, 2012)

Holger Rhinow, Eva Köppen, and Christoph Meinel: "Prototypes as Boundary Objects in Innovation Processes". Conference Paper in the Proceedings of the 2012 International Conference on Design Research Society (DRS 2012), Bangkok, Thailand, July 2012

TAGS

2012 • between domains • between stakeholders • boundary objects • Christoph Meinel • design concepts • design phase • design prototypesdesign solutionsdesign teams • develop ideas • Eva Koppen • financing • first insights • foster communication • Holger Rhinow • impact of prototypes • innovationinnovation process • innovation processes • International Conference on Design Research Society • management perspective • marketing process • organisational designorganisational teamspositive effectsproduction processprototype • prototypes • prototyping • stakeholder management • structured dialogue

CONTRIBUTOR

Simon Perkins
26 SEPTEMBER 2012

Writing a Requirements Document For Multimedia and Software Projects

"Requirements include descriptions of system properties, specifications for how the system should work, and constraints placed upon the development process. Generally, requirements are statements of what a system should do rather than how it should do it. The answers to how questions fall into the realm of design. Requirements specifications should not include design solutions (except for interface requirements, which often include embedded design).

Requirements come from end users, from customers, and sometimes from developers. End users tend to state requirements in descriptive or narrative terms ('I'd like a welcome screen with links to the things I use regularly, and I want to be able to select from a couple of different color schemes for the welcome screen') which might need to be broken down into individual requirement statements. Customers, who may well be different from end users, are the people who are paying for the development of the system. Their requirements will often be stated in terms of costs or scheduling issues. Developers might have requirements related to system performance and other technical topics.

It's important to have all these groups contribute to the requirements document to create a fuller description of the system. The practice of including these groups also helps to ensure that everyone is in agreement about what is to be done before development begins.

Requirements documents usually include user, system, and interface requirements; other classes of requirements are included as needed. User requirements are written from the point of view of end users, and are generally expressed in narrative form: The user must be able to change the color scheme of the welcome screen. System requirements are detailed specifications describing the functions the system needs to do. These are usually more technical in nature: The system will include four preset color schemes for the welcome screen. Colors must be specified for the page background, the text, visited links, unvisited links, active links, and buttons (base, highlight, and shadow). Interface requirements specify how the interface (the part of the system that users see and interact with) will look and behave. Interface requirements are often expressed as screen mock–ups; narratives or lists are also used."

(Rachel S. Smith, California State University Center for Distributed Learning)

1

TAGS

business logic • business needs • California State University • design solutions • desirable requirement • documented characteristic • expressed in narrative form • functional explanation • functional requirement • functional requirements document • in scope • interface requirements • mandatory requirement • non-functional requirement • operational narrative • optional requirement • out of scope • performance qualification • planning document • prioritisationproject requirementsproject scopequality assurance • requirement statements • requirements document • requirements documentsrequirements elicitationrequirements gatheringrequirements prioritisationrequirements processrequirements specification • requirements specifications • software development process • software engineeringsoftware system • specific needs • system constraints • system properties • system requirements • user acceptance testing • user requirement specification • user requirements • user requirements document • validation process

CONTRIBUTOR

Simon Perkins
Sign-In

Sign-In to Folksonomy

Can't access your account?

New to Folksonomy?

Sign-Up or learn more.