Use cases and user stories are two popular ways to capture functional requirements. They’re both goal-oriented (a very good thing), can be discovered during user / customers workshops, can be easily combined withUX activities, and are used in Agile contexts.
Use cases and user Stories look similar; actually, they’re different. Here is the list of 14 major differences I’ve observed:
- A user story is a brief description of functionality as viewed by the user (Role → Goal); it doesn’t model the interaction between the actor and the system, what the use case does. A user story is not a sequence of actions.
- A user story is short and consist in one or two sentences written in the language of the user (example: As a recruiter, I can submit job vacancies). A role and a goal, then it is discussed. A use case is heavier, richer in information: goal, summary, actor, precondition, trigger event, main success scenario and extensions (alternative paths, errors …). Use case is (too much) detailed.
- A user story is smaller and can finally be seen as a part of a specific use case: the main success scenario or an extension
- User stories are used for planning. They play a major role in project estimation and planning (via story points and velocity). Use cases are not used for planning, even if you can use “use cases points” technique to estimate project size.
- User stories emerge faster than use cases; use cases require more time for analysis and writing
- User stories are more readable than use cases; use cases usually belong to a large word document, often poorly written and difficult to read even in a structured template
- User stories are easier to maintain than a 150 pages Use cases Document
- User stories are based on verbal communication and rely on collaboration, discussion and proximity to clarify details. Use case is a textual model (associated with diagrams): every thing is written !
- User stories are in theory written on cards (remember the 3 C rule: Card, Conversation, Confirmation): they’re not intended to be archived unlike use cases.
- A user story must be implemented and tested in one iteration; a specific use case can be implemented in several iterations: main success scenarion on iteration 1; extensions in Iteration 2 and 3 …
- User stories can be more easily written by a user or customer; most of the time use cases are written by user proxies (BA, Consultants …)
- User stories contain acceptance tests (validation criteria) written on the back of the story card; use case not: tests cases are created in a separate documentation
- Use cases provide a more holistic view of the system: precondition, UC diagram, sub use case. Linking user stories is less obvious. This is also a reason why UX and IxD activities are so important in agile contexts !
- Finally, Use cases and user stories were originally associated with two different methodologies (Unified Process vs eXtreme Programming). But both can be used with agile methods and unified process !
My preference:
I have almost a ten years experience with use cases. Alistair Cockburn’s book “Writting effective use cases” used to be my bible for years… but now, my preference tends to go to user stories model. And this is usually my recommendation to Agile Teams.
Why ?
- User stories focus on what is really important
- User stories are more appropriate for collaboration
- User stories can perfectly be combined with UX activities (Personas, Storyboard, Wireframes):
User stories + UX artifacts = Just enough
http://www.agile-ux.com/2009/01/23/use-cases-user-stories-so-precious-but-not-the-same/
'개발언어관련' 카테고리의 다른 글
| 유스케이스와 사용자 스토리 (0) | 2012/01/30 |
|---|---|
| 이클립스 php 플러그인 다운로드 사이트 (0) | 2010/05/11 |
답은 간단한다.
ASP.net을 위한 필요한 권한을 가진 사용자를 생성한다.
web.config 파일에
아래의 글을 삽입한다.
<identity impersonate="true" userName="위에서 만든 사용자 이름" password="위에서 만든 사용자 비밀번호" />
참고 할 문서는
C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config.comments
이다.
ASP.net을 위한 필요한 권한을 가진 사용자를 생성한다.
web.config 파일에
아래의 글을 삽입한다.
<identity impersonate="true" userName="위에서 만든 사용자 이름" password="위에서 만든 사용자 비밀번호" />
참고 할 문서는
C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config.comments
이다.
'개발언어관련 > C#' 카테고리의 다른 글
| ASP.net으로 웹서비스를 개발할 때 unathorizedaccessexception 해결 (0) | 2011/08/18 |
|---|---|
| Bluetooth Application Development (0) | 2010/03/10 |
| STA, MTA (0) | 2009/12/23 |
| C# 한글 텍스트 파일 불러와서 한글로 저장할 때 깨짐 방지 (0) | 2009/09/10 |
myDB.db에 엑셀의 데이터를 넣기를 한다고 하면,
1. 엑셀에 있는 데이터를 다른 이름으로 저장 - 다른 형식 메뉴를 선택하면 다른 이름으로 저장 대화상자가 나타난다. 주의 사항 : 줄바꿈은 데이터베이스에 입력되지 않으므로 적절한 단어로 대체해줘야 한다.
2. 파일 형식을 텍스트(탭으로 분리) 를 선택한다. 그리고 저장한다. myDB.txt로 저장했다고 가정함.
3. 아래와 같은 명령으로 sqlite3 명령을 통해서 myDB.db를 open한다.
sqlite3 myDB.db
4. 엑셀을 텍스트로 저장할 때 탭으로 분리를 선택했기 때문에 아래와 같은 명령으로 구분자를 탭으로 명시한다.
.separator "\t"
5. 데이터가 들어갈 테이블을 만들어 준다. 텍스트 파일의 컬럼의 순서와 테이블의 컬럼의 순서가 일치해야 한다. 데이터 타입은 적절하게 주면 되겠다. ,테이블 명은 Ttest로 가정함.
6. 아래와 같은 명령으로 텍스트 파일의 데이터를 테이블로 가져온다.
.import myDB.txt Ttest
1. 엑셀에 있는 데이터를 다른 이름으로 저장 - 다른 형식 메뉴를 선택하면 다른 이름으로 저장 대화상자가 나타난다. 주의 사항 : 줄바꿈은 데이터베이스에 입력되지 않으므로 적절한 단어로 대체해줘야 한다.
2. 파일 형식을 텍스트(탭으로 분리) 를 선택한다. 그리고 저장한다. myDB.txt로 저장했다고 가정함.
3. 아래와 같은 명령으로 sqlite3 명령을 통해서 myDB.db를 open한다.
sqlite3 myDB.db
4. 엑셀을 텍스트로 저장할 때 탭으로 분리를 선택했기 때문에 아래와 같은 명령으로 구분자를 탭으로 명시한다.
.separator "\t"
5. 데이터가 들어갈 테이블을 만들어 준다. 텍스트 파일의 컬럼의 순서와 테이블의 컬럼의 순서가 일치해야 한다. 데이터 타입은 적절하게 주면 되겠다. ,테이블 명은 Ttest로 가정함.
6. 아래와 같은 명령으로 텍스트 파일의 데이터를 테이블로 가져온다.
.import myDB.txt Ttest
'스마트폰 개발 > 안드로이드' 카테고리의 다른 글
| 엑셀의 데이터를 SQLite3로 가져오기 (0) | 2011/06/03 |
|---|---|
| 윈도우, 맥에서 구글맵 API 키 발급받기 (0) | 2010/08/26 |

Prev
Rss Feed