안마의자

하나 사고 싶다 ^^;



그림은 610만원짜리...... -_-;

공상허언증

"황당할 정도로 당당한 신씨의 거짓말의 정체는 뭘까. 정신과 전문의들은 "정확한 판단은 자세한 상담을 통해 밝혀지겠지만 아마도 자신의 거짓말을 스스로 믿어 버리는 '공상적 거짓말(pseudologia fantastica)'일 가능성이 있다"고 분석했다. "진짜 거짓말쟁이는 스스로를 속이는 사람"이라는 말처럼 자신의 거짓말에 스스로 도취돼 진실인 양 믿어 버리는 상태라는 것이다. 대개 일부의 사실에다 다양하고 폭넓은 극적인 공상과 거짓말을 섞어 포장한다고 전문가들은 지적한다. 수술 자국을 전쟁이나 모험 활동 중에 받은 상처로 꾸미는 경우가 대표적이라고 한다."

정도의 차이는 있겠지만, 이런 사람들 너무 많다. -_-;
한때 엄청 유명했던 미국 Donald Trump의 유명 Reality Show인 Apprentice에서 Omarosa도 대표적인 예일것이다. Reality Show인만큼 곳곳에서 카메라가 돌아가고 있는 상황인데도, 나중에 딴소리를 하고 빡빡우겨대니, 전세계 시청자들이 경악을 할 수 밖에 없었다.

일반적인 사람들도 어느정도 자기방어적으로 또는 다른 사람들을 생각해서 의도적으로 거짓말을 하기도 하지만, 신정아류의 공상허언증도 실생활에서 제법 접할 수 있다, 이렇게 우기는 사람을 접하면, 정말 내 기억이 잘못되었나? 내가 잘못 알고 있는 건 아닌가하고 오히려 의심이 들 경우까지 있다.
정말 확실히 모르고 그런 사람 말을 들으면 속아 넘어가는 건 시간문제일 수도 있다.

Establishing Requirements

In Software Engineering, requirements have led to the development of methodological techniques that can be used to gauge and monitor the early stages of the development cycle. And there have been attempts to synthesize requirements engineering techniques for HCI (Human-computer interaction) as well. Software Engineering and HCI share a common concern to identify and analyze the needs of customers and clients, although they are keepers of different views like follows:

What is a requirement?

A requirement is an objective that must be met.
Requirements are instructions describing what functions the software is supposed to provide, what characteristics the software is supposed to have, and what goals the software is supposed to meet or to enable users to meet. Any coherent and reasonable project must have requirements that define what the project is ultimately supposed to do.

Why are requirements important?

Although several decades of industry experienced in requirements endeavors, developers still pursue projects for which the requirements are not clear. These problems persist and the findings are validated by a long list of infamous IT project failures ranging from the very recent to those reaching back nearly as far as computers have existed.
While we may be inclined to associate such failures, they happen in every time. This being the case, the failure of IT projects represents a complex problem that must be thoroughly studied from many perspectives to be fully understood
That’s why one of the major challenges in IT system development is the determination of system requirements.

The importance of getting the requirements right

	How the Customer explained it How the Project Leader understood it How the Analyst designed it How the Programmer wrote it How the Business Consultant described it
	How the project was documented What Operations installed How the Customer was billed How it was supported What the Customer really needed

Why do we need requirements?

The purpose of defining user requirements as described in this step is to prepare for writing an accurate and complete Statement of Work. The Statement of Work is a key element of the Software Contract Package.

When user requirements are well understood from the start of a project, customer satisfaction with the resulting software will be higher.

1. Project scoping
   
2. Cost estimating
   
3. Budgeting
   
4. Project scheduling
   
5. Software design
   
6. Software testing
   
7. Documentation and training manuals
   

Requirement Types

There are several categories of requirements.

User Requirements

User requirements typically describe the needs, goals, and tasks of the user. Sometimes these user requirements don't reflect the actual person who will be using the software. Projects are often tailored to the needs of the project requestor, and not the end-user of the software.

System Requirements

System Requirements has two meanings. First, it can refer to the requirements that describe the capabilities of the system with which, through which, and on which the product will function. Second, it can refer to the requirements that describe the product itself, with the meaning that the product is a system.

There are two categories of system requirements.

• Functional requirements specify what the system must do. To document functional requirements you must capture three categories of information:
  
• Use Cases define a step-by-step sequence of actions between the user and the system.
  
• Functional Capabilities define what specific action the system should take in a given situation.
  
• Business Rules state the condition under which a use case is applicable and the rule to be applied.
  
• User requirements specify the acceptable level of user performance and satisfaction with the system.
  

Functional Specifications

Functional specifications describe the necessary functions at the level of units and components; these specifications are typically used to build the system exclusive of the user interface.
The functional specification is what you are thinking about when you are doing requirements.

• User requirements is details what the user expects to see and do
  
• Domain requirements is requirements imposed by the application domain of the system.
  

Technical Specifications

Technical specifications are typically written the by developers and coders, and describe how they will implement the project.

Non-Functional Requirements

Non-functional requirements are requirements which are not directly mapped to a scenario or use case. Usually they represent lateral issues such as security, scalability, performance etc. To make it easier to capture non-functional requirements, we organize them into five categories:

• Usability: describes the ease with which the system can be learned or used.
  
• Reliability: describes the degree to which the system must work for users.
  
• Performance: specifications typically refer to response time, transaction throughput, and capacity.
  
• Supportability: refers to the software's ability to be easily modified or maintained to accommodate typical usage or change scenarios.
  
• Security: refers to the ability to prevent and/or forbid access to the system by unauthorized parties.
  

Design Specifications

The design specifications address the "look and feel" of the interface, with rules for the display of global and particular elements.

Diagrams

• Flow diagrams define the end-user's paths throng the site and site functionality.
  
• Logic diagrams describe the order that logic decisions are made during the transmission, gathering, or testing of data.
  
• System Architecture Diagram illustrates the way the system hardware and software must be configured, and the way the database tables should be defined and laid out.
  

Prototypes and Mock-up

• Prototype is a model of the system delivered in the medium of the system. For example, a web site prototype would be delivered as a web site, using the standard web protocols, so that it could be interacted with in the same medium as the project's product.
  
• Mock-up is a representation in a different medium. A web site mock-up might be a paper representation of what the pages should look like.
  

Reviewing Requirements

There are many issues that we must consider when reviewing requirements. As you will see, they are all derived from the things that make requirements so important. The requirements review is not focused on mentoring and guidance, but mainly on establishing the correctness and feasibility of requirements. The following issues are in fact a breakdown of this meta-goal.

Characteristics of Good Requirements

Good requirements have several useful properties, such as being consistent, necessary, and unambiguous.

Clarity

The requirements represent the customer's expectations from the product. The development team and the QC team should create a product that meets these expectations. The first condition to the success of the project is to gain a real and whole understanding of what needs to be done.

Feasibility

After verifying that the requirements are clear and that they are well understood by all the participants in the development process, we need to verify that they are feasible. The meaning of feasibility in this context requires some clarification. The chances that your customer will ask for something which is impossible to implement are not very high. So, why is this an issue that requires your attention in a requirements review? Well, the fact that something is theoretically possible does not guarantee that it is feasible under the constraints of a concrete project.

Testability

There are two issues related to testability in the context of reviewing requirements. The first relates to the issue of clarity. Vague requirements are often untestable. The second aspect of testability is assuring that requirements could be indeed verified.

Completeness

Now, sometimes not everything is known a-priory. However, you must realize that leaving major holes in the requirements specification is a risk. These missing requirements are bound to appear sometime during development. At that stage, they might require major changes in the design of the product or in its already implemented sections.

Project Planning

One of the things that make requirements so important is the fact that they are essential for project planning. The primary concern in project planning is verifying that the resources you have (including human resources and time resources) are sufficient in order to meet the customer's expectations. More than a few projects failed because too many features were expected while the lack of sufficient resources simply made it impossible to deliver the full-featured product on time.

Requirements are one of the first artifacts in the process of creating a software product. It is also the most important one, in the sense that without it there would be no development. Errors, wrong decisions and vagueness in the requirements are hard to find. Nevertheless they have a great cost. If a vague or ambiguous requirement is found only when testing the product it has a major cost impact on the entire development process: there will be a need to reopen the requirements, discuss them with the customer, analyze the modified requirements, redesign the related feature and of course change its implementation. In fact, many projects fail because of such problems in the requirements. All this cost could be avoided if such problems would have been found before the requirements are signed as a contract with the customer.

Software Development Process

Someone identifies market opportunities and captures the results of that analysis in a document like an MRD.
Someone determines which of those opportunities should be addressed in software and creates a PRD (or FRS or SRS) capturing the results of that analysis.
Someone designs a software solution based upon those software requirements, and captures that design in a design document.
Someone implements a software solution (writes code) that conforms to the documented design.

Software Development Requirements Process

1. Concept Development
1. Defining Requirements
1. Design
1. Implementation
1. Alpha & Beta Test
1. Final Acceptance Test
1. Support & Maintenance

Software Request for Proposal (RFP)

Before the start of a software development project, a Request for Proposal (RFP) may be issued in order to solicit bids from competing sources. The Project Manager works with the Contracts Group to initiate and complete the RFP process.

Roles

• Project manager is responsible for driving the software development process, following the general timeline as filled in by the project manager, and ensuring software quality.
  
• Software Developer is responsible
  
• QA (Quality Assurance) is responsible for the development process quality checkpoints and for software acceptance testing.
  
• Users are defined as anyone who will use the completed software.
  

My Original Source: https://wiki.dev.hostway/bin/view/Main/EstablishingRequirements