Atjaunināt sīkdatņu piekrišanu

Designing the Requirements: Building Applications that the User Wants and Needs [Mīkstie vāki]

  • Formāts: Paperback / softback, 400 pages, height x width x depth: 232x179x22 mm, weight: 622 g
  • Izdošanas datums: 29-Oct-2015
  • Izdevniecība: Addison-Wesley Educational Publishers Inc
  • ISBN-10: 0134021215
  • ISBN-13: 9780134021218
Citas grāmatas par šo tēmu:
  • Mīkstie vāki
  • Cena: 47,98 €*
  • * Šī grāmata vairs netiek publicēta. Jums tiks paziņota lietotas grāmatas cena
  • Šī grāmata vairs netiek publicēta. Jums tiks paziņota lietotas grāmatas cena.
  • Daudzums:
  • Ielikt grozā
  • Pievienot vēlmju sarakstam
  • Formāts: Paperback / softback, 400 pages, height x width x depth: 232x179x22 mm, weight: 622 g
  • Izdošanas datums: 29-Oct-2015
  • Izdevniecība: Addison-Wesley Educational Publishers Inc
  • ISBN-10: 0134021215
  • ISBN-13: 9780134021218
Citas grāmatas par šo tēmu:

End users are often dissatisfied with IT applications. Often, the problem isn't that those applications were badly implemented: rather, they may be performing the wrong task, or doing the right thing clumsily. Why do these failures happen? Often, the cause can be traced directly to problems with the way requirements were captured upfront.Designing the Requirements: Building Applications that the User Wants and Needswill help you get requirements right, by taking a professional, design-focused approach to them, as you build deeper, stronger relationships with all your project stakeholders.

 

Leading requirements consultant and software designer Chris Britton shows how to systematically detect inconsistencies, incompleteness, poor usability, and misalignment with business goals upstream, long before your development organization starts implementing the solution.

 

Britton also shows application designers and developers how to give stakeholders and users the guidance they need to clarify true needs, concerns, and tradeoffs - rather than simply giving them what they say they want, without adequate exploration. Just as those who are commissioning a new building need professionals' wisdom on avoiding floods and preparing for earthquakes, so too do software customers need your wisdom on software requirements and design: this book shows how to develop and offer that wisdom in ways that deepen and strengthen your relationships with every project stakeholder: end users, business managers and analysts, and other IT project teams.

  • Part I explains why establishing requirements is a true design exercise, and illuminating the unique requirements and design problems of large applications.
  • Part II explains how to capture high-value knowledge about what users want; why the business chose this project; constraints the society places on your design; challenges of integration with other IT projects and infrastructure; and key issues in project control and development.
  • Part III addresses program design for functionality, security, performance, and the full program lifecycle (including testing, debugging, monitoring, and control)

Designing the Requiremens helps you systematically bridge the gaps between IT and your business, so your designers and developers can build software that really will delight the people who use and pay for it.

Preface xiii
Acknowledgments xxi
About the Author xxiii
Chapter 1 Introduction to Context-Driven Design
1(22)
Designing Requirements
2(7)
What Is Design?
9(10)
Ad Hoc Design
12(2)
Planned Design
14(1)
Engineered Design
14(4)
Summary of Design Approaches
18(1)
Making IT Application Development More of an Engineering Discipline
19(1)
Taking IT Architecture into Account
20(1)
Concluding Remarks
21(2)
Chapter 2 A Hierarchy of Designs
23(30)
Justifying the Hierarchy of Designs
23(5)
Context Design
28(7)
Tasks
28(2)
User Groups
30(1)
Data Tables
30(1)
Messages between Tasks
31(1)
Task Dependencies
31(1)
Putting It All Together
32(2)
Analysis of the Context Design
34(1)
Integration Design
35(6)
Technical Design
41(3)
User Interface Design
44(2)
Database Design
46(1)
Implementation
47(1)
Is It Really Engineering?
48(3)
Concluding Remarks
51(2)
Chapter 3 Reusing Existing Methods and Practices
53(30)
Agile
54(6)
Individuals and Interactions over Processes and Tools
55(1)
Working Software over Comprehensive Documentation
56(2)
Customer Collaboration over Contract Negotiations
58(1)
Responding to Change over Following a Plan
59(1)
Conclusion
60(1)
Upside-Down Design
60(2)
Use Cases
62(6)
Atomicity
63(1)
Confusion of Design Layers
64(2)
Use Cases Are Confusing
66(1)
Large Use Case Documents Are Hard to Understand
67(1)
Use Cases Do Not Assist Engineered Design
67(1)
Conclusion
68(1)
The Problem with Estimating Cost
68(4)
Why Is BDUF Big?
72(2)
Iterations
74(1)
Quality
75(1)
Testing and Inspection
76(2)
Using Existing Practices in Context-Driven Design
78(2)
Learning Organizations
80(1)
Concluding Remarks
80(3)
Chapter 4 The Problem of Large Applications
83(22)
The Dimensions of Size
84(4)
Problems with Large Projects
88(12)
Requirements Problems
88(3)
Lack of End User Support
91(2)
Technical Design Problems
93(3)
Procurement and Outsourcing
96(4)
Can Large Projects Be Avoided?
100(3)
Concluding Remarks
103(2)
Chapter 5 The Relationship with the Business
105(24)
Understanding Business Processes
106(6)
When It's Not a Process
112(3)
Business Services
112(1)
Resource Management
113(2)
Reviewing and Monitoring
115(1)
The Need for a Wider View
115(3)
Applying the Business Strategy to Application Development
118(5)
Speed of Development
119(1)
Cost versus Performance and Availability
119(1)
Experimental Business Programs
120(1)
How Long Before the Benefits
120(1)
The Need for Security
120(1)
Designing for the Existing Culture
120(1)
Design for a Culture to Which the Organization Aspires
121(1)
Allow for Changing Plans
122(1)
Support a Learning Organization
122(1)
Non-Business Applications
122(1)
Analysis
123(5)
Is the Process Well Formed?
123(1)
Dependency Analysis
123(4)
Objectives Analysis
127(1)
Concluding Remarks
128(1)
Chapter 6 The Relationship with the Users
129(30)
Adding the Detail
129(12)
Task Details
131(4)
Task Fragments
135(1)
Common Purpose Groups
135(1)
Data Tables
136(1)
Messages
137(1)
Nonfunctional Requirements
138(2)
Who Uses the Context Design?
140(1)
Who Are the Users?
141(10)
Business Process Operations
142(1)
Monitoring by Management
143(4)
Data Used by Other Applications
147(1)
Data Analysis
148(1)
Application Administration
149(2)
Analyzing the Context Design
151(5)
Process Layer
151(2)
Task Details
153(1)
Data Table Details
154(1)
User Group Details
155(1)
Message Details
155(1)
Reviewing the Context Design
156(2)
Concluding Remarks
158(1)
Chapter 7 The Relationship to Other IT Projects
159(30)
Integration Design
161(9)
Applications
161(1)
Services
162(3)
Databases
165(5)
Services Interface Design
170(8)
Service Interface Definition
172(4)
Designing Reusable Services
176(2)
Existing Applications
178(8)
Knowing What Is There
178(2)
Replacing Existing Applications
180(4)
Fashioning Services from Existing Applications
184(2)
Looking Back at the Design Process
186(2)
Concluding Remarks
188(1)
Chapter 8 User Interface Design and Ease of Use
189(26)
Logical User Interfaces
191(3)
From Tasks to Clicks
194(5)
Ease of Use
199(9)
Function
200(1)
Information
201(1)
Navigation
202(1)
Text
202(1)
Help
203(1)
Intuitive and Likable Applications
203(2)
Ease-of-Use Design
205(3)
Monitoring Ease of Use
208(1)
Transaction and Task Integrity
208(4)
The User Interface Design and the Other Detailed Designs
212(1)
Concluding Remarks
212(3)
Chapter 9 Database Design
215(28)
Database Design
215(8)
Database Design Theory
223(10)
Programmers versus the Database Designer
233(3)
Database Access Services
236(2)
NoSQL
238(4)
Concluding Remarks
242(1)
Chapter 10 Technical Design---Principles
243(28)
Principles of High Performance on a Single Machine
244(8)
Cache
245(3)
Multithreading and Multiprocessing
248(4)
Principles of High Performance on Many Servers
252(8)
Front-End Parallelism
252(4)
Back-End Parallelism
256(4)
Principles of High Resiliency
260(3)
The Need for Testing and Benchmarking
263(2)
The Technical Design Process
265(3)
Concluding Remarks
268(3)
Chapter 11 Technical Design---Structure
271(26)
Program Structure
272(4)
What Is a Framework?
276(5)
The Variety of Programming Languages
281(5)
Choosing a Programming Language and Framework
286(4)
Choose a Language that Fits Your Organization's Skill Set
287(1)
Choose a Language that Is Appropriate for Your Application's Performance Goals
287(1)
Choose a Language that Can Meet Your Integration Requirements
287(1)
Choose a Language that Supports Group Working If Needed
287(1)
Choose Version Control Software and Project Management Software as Well as a Language
288(1)
Choose a Language that Chimes with Your Development Methodology
289(1)
Extending the Framework
290(3)
Implementing Common Functionality
293(2)
Concluding Remarks
295(2)
Chapter 12 Security Design
297(26)
IT Application Security Principles
299(8)
Authentication
300(2)
Access Control
302(1)
User Administration
303(1)
Security Protection
304(2)
Security Monitoring
306(1)
The Security Elements of Each Design
307(9)
Context Design
307(4)
Integration Design
311(1)
User Interface Design
312(1)
Database Design
312(2)
Technical Design
314(2)
Security Programming
316(3)
Concluding Remarks
319(4)
Chapter 13 The Future of Application Development
323(18)
How Context-Driven Design Changes Application Development
323(2)
Context-Driven Design Opportunities
325(7)
New Tools
326(2)
Context and Integration Design
328(1)
User Interface and Database Design
328(1)
Technical Design
329(3)
The Application Development Challenges
332(7)
Flexibility
332(2)
Operations
334(1)
Correctness
335(1)
Quality
336(1)
Professionalism
337(2)
Concluding Remarks
339(2)
Appendix A Context Design Checklist
341(8)
Description
341(8)
Elaboration
344(1)
Analysis
344(5)
References 349(4)
Index 353
Chris Britton is a long-time IT professional. For the last five years he hasrather to his surprisefound himself designing and implementing web applications for business startups. Prior to that, he worked as a consultant, mainly in IT architecture and application development. Before that, for many years he worked for Unisys where did a variety of jobssystem software design; architecture consultancy; fixing large, broken databases; program management; and even marketing. It was while at Unisys he wrote his first IT book IT Architecture and Middleware: Strategies for Builiding Large Integrated Systems.